Интересно, а какой процент при этом дрочил?
Что тут
SHOW VARIABLES LIKE 'skip_name_resolve';
?
Я думал, пару ссылок не помешают.
та нет. тоже так. плюс второй запрос тоже как строка. тут для меня непонятная картина
А Вы второй поправьте для проверки.
Как раз второй не захотел использовать индексы с фильтра, а стал использовать по дате.
Ну или втулите IGNORE INDEX / FORCE INDEX, но это затыкание дыр, а не решение проблемы.
date тип datetime, а остальные тип tinyint
Попробуйте передать в запрос 1, а не '1'
Хотя обычно тупит, если передать наоборот число для поля строки.
Первый запрос решил использовать оптимизацию intersect. Она обычно или сильно решает или сильно тупит.
Только странно почему не хватило индекса approve_allow_main.
Второй запрос тупо использовал индекс по дате для сортировки, что тоже часто является неоптимальным, а тут порешало.
Возможно типы данных не совпадают где-то. Везде строки?
Кстати, может версия старая?
Берите любые
Можно начинать с дешевых
Можно прослушать перед покупкой может в офлайне
А то что дорогие, что дешевые - особой разницы не заметил
Как повезет
Кмк, так продвигаются только ГС-ы в основном.
Ну и binance.
Обычно да. А если нет?
Хоть ПС и тупые.
Но шлак, кмк, не дает плюса.
