MySQL: Запрос MySQL стал медленным после появления нового индекса

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

После создания индекса MySQL иногда выбирает более медленный план запроса: изменились оценки селективности, статистика или порядок соединения таблиц. Сам факт появления индекса не означает, что он будет использоваться эффективно.

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

1. 1. Выберите один конкретный запросИз медленного журнала или приложения возьмите SQL без паролей и личных данных. Сохраните пример параметров, число строк и длительность до изменения индекса. Убедитесь, что проблема относится к тому же SQL.

1. 2. Проверьте имеющиеся индексыВ mysql-клиенте выполните SHOW INDEX и запишите имя нового индекса, порядок полей и Cardinаlity. Оценка статистики не равна точному числу уникальных значений.

   SQLКомандаКопировать всёВыделить

   Замените appdb.orders на реальную таблицу, чтение.

   SHOW INDEX FROM appdb.orders;

1. 3. Получите план без исполнения запросаВ тестовой базе выполните EXPLAIN перед исходным SELECT, подставив реальный запрос. Посмотрите key, type, rows, Extra; сохраните результат для сравнения после изменения.

   SQLКомандаКопировать всёВыделить

   Только пример; замените таблицу, колонку и условие на реальный SELECT.

   EXPLAIN SELECT * FROM appdb.orders WHERE customer_id = 42;

1. 4. Сравните план со старой версиейНа резервной копии или тестовом сервере до добавления индекса сравните EXPLAIN этого же запроса при схожем объёме данных. Если среда отличается, вывод может быть не сопоставим; учитывайте статистику и параметры сервера.

1. 5. Проверьте статистику индексовЕсли статистика явно устарела, администратор может запланировать ANALYZE TABLE в тестовой базе. Операция обновляет статистику, может влиять на выбор планов и расходовать ресурсы.

   SQLС осторожностьюКопировать всёВыделить

   Только тест/согласованное окно; требует соответствующих прав и может менять планы запросов.

   ANALYZE TABLE appdb.orders;

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

1. 6. Исследуйте избирательностьПроверьте, действительно ли условия WHERE используют первые столбцы составного индекса, сколько строк обрабатывается после фильтрации и нет ли сортировки/filesort. Не добавляйте индекс на каждый столбец без сравнения записей и затрат на INSERT.

1. 7. Тестируйте точечное исправлениеНа тестовой копии сравните переписывание условия, актуализацию статистики или другой состав индекса. Подсказку FORCE INDEX используйте только как измеряемый временный эксперимент: она может ухудшить производительность на иных параметрах.

1. 8. Оцените задержку и соседние запросыЗапустите повторяемую проверку времени выполнения и нагрузки с одинаковыми параметрами. Успех — запрос стал быстрее без ухудшения записи и соседних запросов. Если нет, верните тестовый план и продолжите сбор метрик.

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

В сравнимом тесте запрос выполняется быстрее, план стабилен, другие важные запросы и запись данных не деградировали.

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

Если таблица очень большая, согласуйте анализ и DDL с администратором; работы на продуктивной базе только после резервного копирования и оценки блокировок.