Как определить, что индекс используется в SQL-запросе

Что проверяют

Умеете ли вы читать план запроса, а не гадать по времени выполнения. Для дата-специалиста это ежедневная задача: запрос к витрине тормозит, и надо понять почему. Следом обычно дают план и спрашивают, почему индекс есть, а база его не взяла.

Как отвечать

Основной инструмент EXPLAIN. В PostgreSQL EXPLAIN показывает план и оценки планировщика без выполнения, а EXPLAIN (ANALYZE, BUFFERS) выполняет запрос и добавляет реальное время, число строк и прочитанные страницы. Для UPDATE и DELETE запускайте его в транзакции с ROLLBACK.

В плане ищите узлы:

• Index Scan using idx_name: индекс использован, строки дочитываются из таблицы;
• Index Only Scan: все нужные колонки есть в индексе, таблицу почти не трогают;
• Bitmap Index Scan и Bitmap Heap Scan: индекс собрал набор страниц, их читают пачкой, типично для средней селективности;
• Seq Scan: полный проход по таблице, индекс не использован.

В MySQL смотрят колонки key (выбранный индекс) и type (ALL означает полное сканирование), в ClickHouse EXPLAIN indexes = 1 показывает, сколько гранул отсёк первичный ключ.

Затем назовите, почему индекс не берётся: запрос возвращает большую долю таблицы, и последовательное чтение дешевле; статистика устарела (лечится ANALYZE); над колонкой функция или приведение типа; LIKE '%текст' с ведущим шаблоном; в условии нет первой колонки составного индекса.

История использования есть в pg_stat_user_indexes: колонка idx_scan показывает, сколько раз индекс применялся с момента сброса статистики.

Где спотыкаются

Делают вывод по одному прогону: второй запуск быстрее из-за кэша, а не из-за индекса. Смотрите план и BUFFERS, а не секундомер.

Считают Seq Scan всегда ошибкой. На маленькой таблице или при выборке половины строк это правильное решение планировщика.

Проверяют на локальной базе с сотней строк. План зависит от объёма и статистики, на проде он будет другим.