Приходилось ли отлаживать большие или медленные SQL-запросы
Что проверяют
Идёте ли вы от плана запроса, а не от догадок, и понимаете ли, что в проекте на ORM самая частая причина медленной страницы это не один тяжёлый запрос, а сотня лёгких в цикле.
Как отвечать
Опишите маршрут. Сначала найти виновника: журнал медленных запросов, статистика по запросам на стороне базы, панель отладки фреймворка, где видно и число запросов на страницу. Потом посмотреть план: EXPLAIN, а лучше с фактическим выполнением, чтобы сравнить оценку строк с реальностью.
На что смотреть в плане и что обычно чинится:
- полный проход по таблице там, где ожидался индекс;
- функция над колонкой в условии, вроде
WHERE DATE(created_at) = ...: индекс после такого не используется, нужен диапазон по времени; - разные типы в сравнении, из-за чего срабатывает неявное приведение;
- сортировка и временная таблица, ушедшие на диск;
- постраничная выборка с большим смещением, которая заставляет базу прочитать и выбросить всё до нужной страницы. Лечится переходом на условие по последнему ключу.
Для PHP-части скажите про жадную загрузку связей вместо запроса в цикле и про обработку больших выборок кусками, иначе процесс упрётся в лимит памяти.
Где спотыкаются
Накрывают плохой запрос кешем. На холодном старте и при сбросе кеша всё возвращается, данные начинают показываться устаревшими, а исходная проблема остаётся на месте.
Вешают индекс на каждую колонку из условия. Запись становится дороже, место растёт, а для конкретного запроса оптимизатор всё равно выберет один путь доступа: чаще нужен составной индекс с правильным порядком колонок, он работает слева направо.
Смотрят на запрос в отрыве от кода и проверяют его на маленькой копии базы. На тысяче строк план другой, а сам по себе быстрый запрос оказывается вызванным в цикле по всему списку: чинить надо число обращений, а не текст запроса.