אינדקסים מורכבים וחלקיים

בשיעורים קודמים כיסינו שימוש באינדקסים עבור שאילתות DBMS ליניאריות (WHERE country = 'Italy'). מה לגבי כשאנחנו מחפשים בשתי חזיתות משולבות?

לדוגמה, במסחר אלקטרוני אמיתי אולי נרצה למצוא הזמנות ששייכות למזהה לקוח ספציפי ו נופלות בטווח זמן נתון: WHERE customer_id = 90 AND placed_at >= '2025-01-01'.

אם יש לך רק אינדקס בסיס על customer_id, Postgres ימצא את 50 ההזמנות של הלקוח תוך זמן קצר באמצעות העץ הבינארי, אך לאחר מכן היא תצטרך לעבור על כל 50 אותן באופן ידני וברצף, לסנן בעצלתיים את התאריכים לפי עין.

אינדקסים מורכבים

אנו יכולים לומר ל-DBMS להזמין את קבצי "המילון האנליטי" לא לפי מימד מפתח בודד, אלא לאורך כמה.

CREATE INDEX idx_orders_customer_date ON orders(customer_id, placed_at);

אינדקס "מרוכב" מתייחס לסדר הפרמטרים שלו כחשוב מאוד: כאן צמתי B-Tree מקבצים ומסווגים בקשיחות את customer_id בבלוק (המאבחן ביותר להפרדה); בתוכם חי תת-העץ המסתעף עם ערכי הזמן השונים placed_at בסדר ממוין בצורה מושלמת.

המבנה הזה מחסל באכזריות WHERE סעיפים עם פרדיקטים מקוננים מרובים.

אינדקסים חלקיים (אינדקסים מסוננים)

כל אינדקס עולה שטח דיסק ו-CPU בזרמי קלט משתמש. מה אם המסחר האלקטרוני דורש כל הזמן מיון ושליפה של מסנן, אבל רק עבור מיעוט רשומות? (לדוגמה: בדיקה מהירה של בדיקת ההודעות שלא נקראו.) יצירת אינדקס "נקרא" על כל 10,000,000 ההתראות היא מייגעת להפליא אם "לא נקרא" מייצגת רק 5 מהן.

CREATE INDEX idx_unread_notifs ON notifications(user_id)
  WHERE is_read = false; -- Questa aggiuntiva è l'"Indice Parziale"

בסיס הנתונים יבנה B-Tree במהירות הבזק המאחסן מפתחות גישה מהירה ל-DB רק אם הרשומה לא נקראה! הדיסק יתאהב באינדקס של 5 שורות (3 בתים) במקום אחת עם 10 מיליון. Fast SELECTs מרוויחים באופן מלא:

SELECT * FROM notifications WHERE user_id = 2 AND is_read = false;

התור שלך

בחינת אינדקסים מותנים (חלקיים).