MySQL и MariaDB LinuxWindowsMySQL Server

MySQL: Как безопасно проверить план выполнения медленного запроса MySQL

  • Обновлено
  • Чтение ≈ 2 минуты

Краткий ответ

Перед оптимизацией медленного запроса MySQL можно увидеть его план через EXPLAIN, не выполняя сам запрос, однако EXPLAIN ANALYZE действительно выполняет SELECT. На рабочей базе важно сначала получить план с минимальным риском.

В этой статье
  1. Как проявляется проблема и где искать причину
  2. Пошаговая диагностика и устранение
  3. Как проверить результат
  4. Если исправление не помогло

#Как проявляется проблема и где искать причину

Перед оптимизацией медленного запроса MySQL можно увидеть его план через EXPLAIN, не выполняя сам запрос, однако EXPLAIN ANALYZE действительно выполняет SELECT. На рабочей базе важно сначала получить план с минимальным риском.

Возможная причинаКак узнатьЧто делать
Неоптимальный доступБольшой rows и полное сканирование таблицыtype=ALL при большом объёме строкПроверить индексы и условия
Ошибочная оценкаОптимизатор неверно оценивает селективностьОценка rows не соответствует данным тестаСравнить статистику после безопасного анализа

#Пошаговая диагностика и устранение

  1. 1. Найдите именно тот SELECT, который медленныйВозьмите SQL из приложения или медленного журнала, обезличьте параметры. Зафиксируйте время выполнения, пример значений фильтров и схему базы. Не считайте одинаковыми планы запросов с радикально разными параметрами.
  1. 2. Проверьте роль подключенияОткройте отдельную сессию mysql с правами только на чтение. В ней выберите нужную базу и проверьте версию. При нехватке прав запросите администратору безопасный доступ к EXPLAIN.
  2. mysql-клиент, чтение; при DATABASE()=NULL выберите нужную схему
    SQLКоманда
    mysql-клиент, чтение; при DATABASE()=NULL выберите нужную схему.
    SELECT VERSION(), DATABASE();
  1. 3. Получите оценочный планВыполните EXPLAIN перед реальным SELECT. В примере используется условная таблица; замените её на свою. Смотрите type, possible_keys, key, rows и Extra.
    SQLКоманда
    Пример SELECT, замените запрос на реальный; EXPLAIN не выполняет SELECT как EXPLAIN ANALYZE.
    EXPLAIN SELECT id, status FROM appdb.orders WHERE customer_id = 42;
  1. 4. Интерпретируйте признаки сканированияtype=ALL указывает на полное сканирование, но оно не всегда плохо для маленькой таблицы. Проверьте количество строк, фильтрацию и использование составного индекса. Не делайте вывод только по наличию индекса в поле key.
  1. 5. Сверьте реальные индексы и объём таблицыПосмотрите SHOW INDEX и приблизительные сведения о таблице. Убедитесь, что порядок колонок составного индекса соответствует предикатам WHERE и JOIN, а статистика не слишком стара.
    SQLКоманда
    Подставьте нужную таблицу; чтение структуры.
    SHOW INDEX FROM appdb.orders;
  1. 6. Сравните JSON-план при необходимостиДля сложных соединений EXPLAIN FORMAT=JSON показывает дерево доступа и дополнительные оценки. Формат и названия полей зависят от версии MySQL, поэтому сохраняйте версию вместе с результатом.
    SQLКоманда
    Только пример SELECT; чтение плана.
    EXPLAIN FORMAT=JSON SELECT id, status FROM appdb.orders WHERE customer_id = 42;
  1. 7. Измерьте фактическое время только на тестеEXPLAIN ANALYZE выполняет SELECT и может занимать ресурсы. Применяйте его в отдельной копии с сопоставимым количеством данных и безопасными параметрами, а не автоматически в рабочую нагрузку.
    SQLС осторожностью
    Только тестовая среда: запрос действительно исполняется.
    EXPLAIN ANALYZE SELECT id, status FROM appdb.orders WHERE customer_id = 42;

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

  1. 8. Проверяйте каждое изменение сравнениемПосле возможного изменения SQL/индекса на тесте повторите EXPLAIN и измерение времени. Успех — уменьшено число обработанных строк и время выполнения без ухудшения других запросов и записи. При сомнениях возвращайте прежний план теста.

#Как проверить результат

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

#Если исправление не помогло

При запросах с побочными функциями не считайте EXPLAIN универсально безопасным: сначала оцените текст и план выполнения совместно с DBA.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.