- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здрасти
есть тбл и там индекс составной.
выполняю два запроса
первый 13сек. второй 0.028
записей 30к. везде gpt=1 approve=1 allow_main тоже почти везде 1
как понять почему так
https://skr.sh/sPNfuS1OZsS
https://skr.sh/sPNrclKIY4H
Первый запрос решил использовать оптимизацию intersect. Она обычно или сильно решает или сильно тупит.
Только странно почему не хватило индекса approve_allow_main.
Второй запрос тупо использовал индекс по дате для сортировки, что тоже часто является неоптимальным, а тут порешало.
Возможно типы данных не совпадают где-то. Везде строки?
Кстати, может версия старая?
Кстати, может версия старая?
10.6.17-MariaDB
Возможно типы данных не совпадают где-то. Везде строки?
date тип datetime, а остальные тип tinyint
date тип datetime, а остальные тип tinyint
Попробуйте передать в запрос 1, а не '1'
Хотя обычно тупит, если передать наоборот число для поля строки.
Попробуйте передать в запрос 1, а не '1'
Хотя обычно тупит, если передать наоборот число для поля строки.
та нет. тоже так. плюс второй запрос тоже как строка. тут для меня непонятная картина
та нет. тоже так. плюс второй запрос тоже как строка. тут для меня непонятная картина
А Вы второй поправьте для проверки.
Как раз второй не захотел использовать индексы с фильтра, а стал использовать по дате.
Ну или втулите IGNORE INDEX / FORCE INDEX, но это затыкание дыр, а не решение проблемы.
В этот индекс добавьте:
INDEXapprove, allow_main, date DESC
Таблица в Innodb формате?
В этот индекс добавьте:
INDEXapprove, allow_main, date DESC
а зачем? тут нет такого INDEX gpt, approve
а зачем? тут нет такого INDEX gpt, approve
Мы тут тестируем или в теории играем? Если в теории. Я бы 30К записей вообще в файлик записал и не трогал БД.
Мы тут тестируем или в теории играем? Если в теории. Я бы 30К записей вообще в файлик записал и не трогал БД.
я же не всегда буду делать date DESC. будет и ASC
первый 13сек
Что-то абсурдное. При таком количестве записей и при таком запросе эта цифра вообще из серии фантастики, даже если вообще никакие индексы не использовать и никак не оптимизировать запрос, который в данном случае простейший. Ничего не перепутал случаем?