Сталкивался с похожим. виновником оказался — один из интернет-провайдеров хостинг-компании. Причина — маршруты на данный пул адресов не прописаны или каким-то образом изменены и трафик идет через китай.
Они включили на данный VPS второго и все стало нормально.
Сделайте трассировку маршрута в обе стороны. В обратную можно просто до вашего провайдера в спидтесте.
Банально может ограничивать WARP
Есть еще instr это однозначно быстрее like
Ну и fulltext индексы конечно, искать с некоторым языком запросов
p.s. если искать в строках базы приходится ограниченное количество слов (т.е. грубо говоря список слов определяется проектом, а не свободным вводом от пользователя) то можно заранее (при добавлении строк) построить свой собственный индекс, размещая факт наличия подстроки в строке boolean полем true/false или создав соответствующие таблицы (если наличие слов сильно разряжено — это эффективнее), где наличие записи — факт наличия слова.
Например у тебя искать нужно три слова: man, woman, child, соответственно создаешь три boolean колонки has_man, has_woman, has_child в той же таблице где анализируемая строка и заполняешь их триггером.
Или если тот же пример но через таблицы, то в искомой таблице у тебя должно быть primary key поле, и ты создаешь на каждое слово по таблице has_man, has_woman, has_child, с единственным полем id, в эти таблицы помещаешь запись с id из искомой таблицы, если в ее строке есть это слово… это так же можно делать триггером.
А в чем проблема?
$sql = 'SELECT * FROM articles WHERE name LIKE ? AND name LIKE ?'; $prep = $dbh->prepare($sql); $ret = $prep->execute(['%' . 'опух' . '%', '%' . 'поч' . '%']);
Ну, ещё владельцу этого ip можно писать. Особенно если это хостер. Результат для вас не сильно важный вопрос
Выглядит как 272 УК РФ.
Обращаешься в полицию, пишешь заявление — его обязаны будут принять и рассмотреть.
По описанию тут как будто бы есть состав 272, так что должны завести уголовное дело
Абсолютно всё, что торчит в сеть, непрерывно брутфорсится, каждый сервер, каждый маршрутизатор. Если вас ломал не школьник, то IP в логах выведет вас или на публичный анонимный прокси или на ничего не подозревающую жертву ботнета, то есть в никуда.
Я понял, что могу опустить только массив JSON, который я извлекал из столбца, вот так.
select * from events where lower("Key1:VaLuE1") member of(lower(meta->"$.tags"));
Это работает отлично! Спасибо
Вы можете решить проблему поиска без учета регистра в массиве JSON, одновременно гарантируя, что при сравнении строк проверяются точные совпадения (а не частичные совпадения), поэтому вы можете использовать комбинацию JSON_EXTRACT и LOWER. функций
попробуй это
SELECT * FROM events WHERE LOWER(JSON_UNQUOTE(JSON_EXTRACT(meta, '$.tags'))) = LOWER('Key1:VaLuE1'); Мы тестировали и запускали даже с миллионным и не только контентом но и трафиком, вспомните тот же Рутвит, который сделан так же на движке ДСТ, причем треть контента это были видео, платформа спокойно держит, все дело в серверах, вот где главный расход и напряг, платить за серваки много выходит
Если стартап то дороговато, если рабочий бизнес то только ДСТ, так что тут особо без вариантов
Точно фреймворк, на котором пишут CMS системы то есть разные коробки, так что тут нечего гадать
Если верно понял вопрос, то можете добавить в аккаунты как одного плательщика, так и разных. Это не запрещено. Ориентируйтесь на тот вариант, который будет удобнее. Например, оплата с разных юрлиц подойдет, если нужны разные счета по кампаниям. Оплата с одного юрлица позволит упростить отчётность, потому что система автоматически формирует все необходимые отчётные документы.
Им без разницы как им платят. Переводом или с карты. Одно или несколько лиц. Принимают оплату, услугу предоставляют и все документы, включая сверку.
Спасибо за ответ. Ваш обоих детальный разбор показывает глубокое понимание различий между фреймворками и CMS. Благодарю вас за этот интересный и проницательный анализ!