EXPLAIN ANALYZE: как читать план и не попасть в ловушку красивых цифр
Коллеги, давайте разберем план выполнения. EXPLAIN ANALYZE полезен только вместе с фактическим исполнением: план без runtime — это гипотеза, а не диагноз.
Смотрите в первую очередь на:
— расхождение estimated rows и actual rows;
— тип скана: Seq Scan, Index Scan, Bitmap Scan;
— узкие места по времени: Sort, Hash, Nested Loop, Materialize;
— loops: если оператор крутится тысячи раз, проблема часто не там, где кажется.
Важный момент: низкое время одного узла еще не значит, что он безобиден. Посмотрим, что тут с I/O в реальности: буферный кэш, чтение с диска и большие сортировки могут скрываться за «быстрым» планом, пока запрос не упрется в память или конкурентный доступ. А если видите сильный разъезд оценок, сначала проверьте статистику и селективность условий, а не спешите ставить новый индекс.
Полезная привычка: сравнивайте несколько запусков, особенно под разной нагрузкой. Один красивый план на пустой системе и другой под блокировками — это два разных зверя.
Золотое правило: сначала мониторинг, потом индексы. EXPLAIN ANALYZE отвечает не на вопрос «как ускорить вообще», а на вопрос «где именно запрос тратит время и почему».
Оптимизация производительности баз
@database_performance_tuning_arb
EXPLAIN ANALYZE: как читать план и не попасть в ловушку красивых цифр
Этот пост опубликован в Telegram-канале Оптимизация производительности баз. Подписаться можно по ссылке: @database_performance_tuning_arb.