Почему навык чтения плана выполнения запроса — это не просто галочка в резюме, а реальный способ спасать прод от тормозов и неожиданных фулл-сканов.
Когда приходит запрос от разработчика: "Почему тормозит?" — ты открываешь EXPLAIN (ANALYZE, BUFFERS) и видишь:
И тут всё понятно: фильтрация идёт по колонке без индекса, Postgres делает полный проход по таблице. Один CREATE INDEX — и запрос летит
Но не всё так просто. Иногда план говорит:
А запрос всё равно медленный. Почему?
Buffers: shared hit=5 read=100000 dirtied=0 — вот оно. Индекс-то используется, но данные не в кэше, приходится читать с диска. А диск медленный. Решение? Подумать о горячем кэше, пачке RAM или REINDEX, если индекс раздулся.
Каждый EXPLAIN — как рентген. Не читаешь — лечишь наугад.
Когда приходит запрос от разработчика: "Почему тормозит?" — ты открываешь EXPLAIN (ANALYZE, BUFFERS) и видишь:
SQL:
Seq Scan on users (cost=0.00..44231.00 rows=1000000 width=64)
Filter: (status = 'active')И тут всё понятно: фильтрация идёт по колонке без индекса, Postgres делает полный проход по таблице. Один CREATE INDEX — и запрос летит
Но не всё так просто. Иногда план говорит:
SQL:
Index Scan using idx_users_status on users
Index Cond: (status = 'active')А запрос всё равно медленный. Почему?
Buffers: shared hit=5 read=100000 dirtied=0 — вот оно. Индекс-то используется, но данные не в кэше, приходится читать с диска. А диск медленный. Решение? Подумать о горячем кэше, пачке RAM или REINDEX, если индекс раздулся.Каждый EXPLAIN — как рентген. Не читаешь — лечишь наугад.