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