хм... возможно подойти в другом направлении. Это купить VDS с чистым IP и на нём организовать nginx прокси на ваш сервер. По сути тогда у вас будет всё под контролем.
Бесплатно сомневаюсь и то клауд даёт общие IP, а не уникальные.
Если уникальные нужны, тогда VDS или выделенный сервер и там любые IP себе покупайте. Ну или сервисы по ДДОС защите, но там тоже за $$$
т.е. уже диагноз: дело в железе?
А может в ОС? А может быть в версии БД? А может быть в фазе Луны? Или Марс с Юпитером не сошлись и надо подождать?
У кого какие ещё теории... смелее 🤣
текущая база и восстановленная из дампа (даже на той же машине, и даже в синтетических условиях) может дать весьма разные результаты.
И вновь теории...
Сегодня получил письмо от АСЦ, что выплата поставлена в очередь.
Авторизация была полная на киви кошельке с подтверждением паспорта. Поэтому было оправлено только заявление + скан паспорта.
ето куда выложить 30к записей
в SQL файлик и в архивчик.
Добавить составной индекс, который я предлагал... НЕ.... долго это всё...
Выложить SQL файл с чудной это таблицей для теста... НЕ... кому это надо.
Сидеть болтать ни о чём, это ДА! Это время есть! Эт по нашему!
Что-то абсурдное. При таком количестве записей и при таком запросе эта цифра вообще из серии фантастики, даже если вообще никакие индексы не использовать и никак не оптимизировать запрос, который в данном случае простейший. Ничего не перепутал случаем?
Учитывая, что нам нужны только ID из запроса, то я согласен, что 13 сек, это что-то из области фантастики. Но баги никто не отменял. Нужны тесты.
а зачем? тут нет такого INDEX gpt, approve
Мы тут тестируем или в теории играем? Если в теории. Я бы 30К записей вообще в файлик записал и не трогал БД.
В этот индекс добавьте:
INDEXapprove, allow_main, date DESC
Таблица в Innodb формате?
