EXPLAIN ANALYZE: как читать план, чтобы не лечить несуществующую проблему

EXPLAIN ANALYZE: как читать план, чтобы не лечить несуществующую проблему

Коллеги, давайте разберем план выполнения. EXPLAIN показывает, как БД собирается идти к данным, а EXPLAIN ANALYZE — что получилось в реальности: время, число строк, петли, буферы, сортировки.

Смотрите не на один «плохой» узел, а на расхождения между estimate и actual:
— если план ожидал 10 строк, а пришло 10 000, статистика врет или условие слишком широкое;
— если Nested Loop внезапно жует миллионы строк, ищите плохую селективность и отсутствующий индекс;
— если Sort/Hash уходит в диск, посмотрите на память и объем промежуточных данных.

Посмотрим, что тут с I/O в реальности. Полезно читать не только total time, но и loops: 1 ms на узел, повторенный 100 000 раз, легко превращается в пятничный инцидент. Отдельно проверяйте блокировки, чтение с диска и лишние пересчеты выражений: иногда проблема не в запросе, а в функции внутри WHERE, которая убивает использование индекса.

Золотое правило: сначала мониторинг, потом индексы. Сравните план с данными таблицы, статистикой и нагрузкой. Если видите большой перекос между планом и фактом — обновляйте статистику, упрощайте условие, переписывайте JOIN, и только потом добавляйте индекс. В продакшене так лучше не делать, и вот почему: «на глаз» лечат симптомы, а не причину.