הסבירו ונתחו

האם תהיתם פעם איך מסד הנתונים בוחר האם להשתמש באינדקס הנחמד הזה שיצרתם? ברגע שאתה לוחץ על 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 המשני שלנו, תוך שימוש בזמן ביצוע מיקרוסקופי של אלפית השנייה, תוך דילוג על מיליוני שורות תוך כדי תנועה.

התור שלך

קבלת מדדי אמת