ПОЯСНІТЬ і ПРОАНАЛІЗУЙТЕ

Ви коли-небудь замислювалися, як база даних вибирає, чи використовувати той гарний індекс, який ви щойно створили? Щойно ви натискаєте клавішу Enter у запиті (скажімо, довге приєднання до ланцюжкової групи), Планувальник запитів миттєво розраховує десятки стратегій для виконання запиту та вибирає ту, яка теоретично вважається найшвидшою.

Але як розробник, ви повинні вміти зазирнути всередину темного розуму планувальника запитів.

ПОЯСНІТЬ

Щоб дізнатися, як планує діяти планувальник, просто поставте чарівне слово EXPLAIN на початку свого запиту.

EXPLAIN SELECT * FROM orders WHERE status = 'delivered';

Результатом не будуть замовлення! Натомість ви побачите вихідний план (з приблизними статистичними даними):

Seq Scan on orders  (cost=0.00..25.88 rows=15 width=40)
  Filter: (status = 'delivered'::text)

Це говорить нам:

1. Планувальник використовуватиме Seq Scan (грубе, послідовне читання всього диска). Погано, якщо мільярди замовлень.
2. Він оцінює, що буде повернено ~15 рядків, і обчислює «вартість» у попередньо завантажених циклах ЦП.

ПОЯСНІТЬ АНАЛІЗУЙТЕ

У той час як EXPLAIN покладається на алгоритмічні припущення (на основі глобальної статистики, обчисленої за останні кілька годин над даними), EXPLAIN ANALYZE фактично запускає запит у реальному часі (і чекає на повні логічні результати), порівнюючи реальний час, що минув, у математично абсолютних виразах.

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 90;

Index Scan using idx_orders_cust on orders  (cost=0.15..8.13 rows=4 width=40) (actual time=0.012..0.015 rows=4 loops=1)
  Index Cond: (customer_id = 90)
Planning Time: 0.081 ms
Execution Time: 0.033 ms

ура! Тут ви дізнаєтеся, що база даних вирішила застосувати Сканування індексу до нашого вторинного індексу idx_orders_cust, займаючи мікроскопічний час виконання в тисячну частку секунди, пропускаючи мільйони рядків на льоту.

Ваша черга

Отримання правдивих показників