Перейти к содержимому
BXWiki

Запросы к базе - поиск медленных и работа с планом

Медленная страница почти всегда упирается в один запрос, а не во все сразу. Здесь о том, как его найти и что с ним делать.

Что общего у этих задач

Сначала измерение, потом правка. Запрос, который «выглядит тяжёлым», обычно не тот, из-за которого страница ждёт секунду.

План выполнения важнее текста запроса. База сама рассказывает, читает она таблицу целиком или идёт по указателю, и спорить с ней бесполезно.

Индекс ускоряет чтение и замедляет запись. Поэтому их подбирают под реальные запросы проекта, а не расставляют на все поля подряд.

Половина медленных запросов порождена кодом, а не базой. Запрос в цикле по товарам, выборка всех полей и подсчёт итогов на странице дают нагрузку, которую никаким индексом не вылечить.

С чего начать

Начинают с замера на живом сайте, а не на стенде с сотней товаров. Счётчик запросов страницы и журнал медленных запросов базы называют виновника быстрее любых догадок.

Дальше смотрят план выполнения найденного запроса. Он показывает, читается ли таблица целиком, и подсказывает, какого индекса не хватает под этот отбор.

Только после этого берутся за правку. Иногда достаточно индекса, иногда приходится менять сам код: вынести запрос из цикла, ограничить поля выборки или закрыть результат кэшем.

Решения подтемы

Частые вопросы

С чего начать поиск медленного запроса?

С журнала запросов страницы или монитора производительности. Гадать по коду дольше, чем измерить.

Почему запрос быстрый в консоли и медленный на сайте?

На сайте другие параметры и конкуренция за базу. Сравнивать нужно один и тот же запрос под нагрузкой.

Сколько индексов можно добавить?

Столько, сколько оправдано запросами. Каждый индекс замедляет вставку и обновление строк.

Помогает ли кэш вместо индекса?

Помогает до первого сброса кэша. Тяжёлый запрос всё равно выполнится и в худший момент.

Связанные темы

Первоисточники