MySQL и MariaDB LinuxMySQL 8.0/8.4Percona Server 8.0/8.4

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

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

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

Не принуждайте использование индекса до сравнения планов на сходных данных: полный просмотр таблицы может быть быстрее при большой доле подходящих строк.

В этой статье
  1. Что означает неисправность и в каких условиях возникает
  2. Возможные причины: как различить
  3. Пошаговая диагностика и устранение
  4. Как проверить исправление и что делать, если оно не помогло

#Что означает неисправность и в каких условиях возникает

После обновления MySQL/Percona один SQL-запрос стал выполняться медленнее: в EXPLAIN изменился план доступа к таблице, пропал прежний индекс или выросло количество просматриваемых строк. Причиной может быть изменение оценок оптимизатора, статистики или самого SQL, а не поломка индекса. Не принуждайте использование индекса до сравнения планов на сходных данных: полный просмотр таблицы может быть быстрее при большой доле подходящих строк.

#Возможные причины: как различить

Возможная причинаКак узнатьЧто делать
Устаревшие оценки распределения значенийПосле переноса или обновления статистика не отражает реальные данные.EXPLAIN показывает прежний key=NULL или резкую смену rows; данные существенно изменились.Проверить статистику и согласовать ANALYZE TABLE.
Изменились значения и условия WHEREНовый запрос использует функцию на столбце, другое сравнение или тип данных.Текст запроса или тип параметров отличается от прежнего.Вернуть условие, совместимое с индексом, после теста на копии.
Оптимизатор выбрал другой планНовая версия оценивает стоимость иначе.Есть индекс, но key отличается; план на той же копии данных другой.Сравнить версии и планы, проверить реальные времена и индексы.

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

  1. Зафиксируйте версию и конкретный запросВ mysql на сервере выполните SELECT VERSION();, сохраните дату обновления и полный текст проблемного SELECT без личных данных. Сравните его с прежней версией из контроля исходного кода; если поменялись WHERE или JOIN, это уже отдельная причина. Не запускайте дорогой запрос многократно в пик ради измерения.
  2. Снимите безопасный план без выполненияДля проблемного SELECT на испытательной копии запустите EXPLAIN SELECT ...;, подставив фактический запрос. Обычный EXPLAIN для SELECT показывает предполагаемый план; EXPLAIN ANALYZE действительно выполняет запрос, поэтому для тяжёлой боевой таблицы без оценки риска его не используйте.
  3. Сравните колонки планаВ традиционном EXPLAIN смотрите type, possible_keys, key, rows, Extra. possible_keys перечисляет кандидатов, key показывает выбранный индекс; значение NULL означает, что индекс не используется для указанного доступа. Сопоставьте старый и новый планы на максимально близком размере данных и одинаковом SQL.
  4. Убедитесь в наличии индекса и правильных типахВ mysql выполните SHOW INDEX FROM имя_таблицы; с вашим реальным именем, если можете безопасно прочитать структуру. Сравните индексируемые столбцы с JOIN/WHERE и типами соединяемых полей. Функция вокруг столбца, несовпадение строковых наборов или типизация параметра способны ухудшить использование индекса.
  5. Проверьте актуальность статистикиПосле резервной копии и оценки нагрузки на копии базы DBA может выполнить ANALYZE TABLE имя_таблицы; для обновления статистики. Операция анализирует распределение ключей, способна брать блокировки и обычно записывается в бинарный журнал. На боевой базе проводите её в согласованное время, не рассматривайте как абсолютно бесплатную команду.
  6. Сравните план до и после анализаПовторите EXPLAIN тем же SELECT и параметрами. Если key и rows изменились, проверьте фактическую длительность в изолированной копии и число возвращённых строк. Если план не изменился, не повторяйте ANALYZE TABLE циклически: нужны другие сведения о распределении и оптимизаторе.
  7. Попробуйте правку запроса на копииПерепишите фильтр так, чтобы индексируемое поле использовалось напрямую, без ненужных CAST/функций. Проверьте равенство результата старой и новой формулировки на тестовых данных. Добавление нового индекса или FORCE INDEX обсуждайте только после сравнения планов и стоимости записей; индекс сам по себе увеличивает затраты на обновление.
  8. Сохраните способ отката и измерьте эффектВыпустите исправление запроса обычным развёртыванием с возможностью отката версии; для схемы нужна отдельная резервная копия и миграция назад. Снимите время выполнения и количество чтений за одинаковое окно нагрузки. Если оптимизация ухудшила другой запрос, отмените изменение и разберите его план отдельно.
  9. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1SQL на сервере для подтверждения версии MySQL/Percona.
    SQLКоманда
    SQL на сервере для подтверждения версии MySQL/Percona.
    SELECT VERSION();
    Вариант 2Демонстрационный запрос для тестовой таблицы demo_orders.
    SQL
    Демонстрационный запрос для тестовой таблицы demo_orders. Для реального проекта замените и таблицу, и условие, а не запускайте этот пример вслепую.
    EXPLAIN SELECT * FROM demo_orders WHERE customer_id = 42;
    Вариант 3Только тестовая база или согласованное окно у DBA; обновляет статистику, возможны блокировки и репликация, …
    SQL
    Только тестовая база или согласованное окно у DBA; обновляет статистику, возможны блокировки и репликация, поэтому не является командой только для чтения.
    ANALYZE TABLE demo_orders;

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

Успех — на одинаковых данных время выбранного SELECT снизилось, план объясним, строки результата не изменились, побочных регрессий в других запросах нет. Если после обновления статистики план всё ещё плох, соберите EXPLAIN, SHOW INDEX и версии сервера для DBA; не откатывайте всё обновление без оценки безопасности и совместимости.

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

MySQL: ERROR 1045 (28000) Access denied for user — причины и решение Проверьте пароль, хост пользователя и привилегии. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS MySQL: ERROR 2002 — Can't connect through socket — причины и решение Запустите mysqld и проверьте путь сокета. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS 1045 MySQL ERROR 1045 (28000): Access denied for user — как исправить `ERROR 1045 (28000): Access denied for user` значит, что сервер MySQL отклонил вход: неверный пароль, пользователь не существует для этого хоста, у него нет прав или исп… Программирование и базы данных MySQL и MariaDB MySQLMariaDB 1064 MySQL: ERROR 1064 — You have an error in your SQL syntax — причины и решение Ошибка 1064 — синтаксическая ошибка в запросе. Ниже — причины и порядок действий от простого к сложному. Программирование и базы данных MySQL и MariaDB LinuxWindows 1146 MySQL: ERROR 1146 — Table doesn't exist — причины и решение Таблица не найдена: неверная база, регистр имени в Linux или не применены миграции. Проверьте USE и SHOW TABLES. Программирование и базы данных MySQL и MariaDB LinuxWindowsmacOS

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

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