"SUPER INDEX"

Question

כחלק מה"ירושה" שקבלתי כ DBA שעזב, אני מוצא הרבה טבלאות עם אינדקסים שמכילים את כל השדות.

כלומר COVERED INDEX עם שדה אחד מאונדקס (בד"כ השדה שמייצג את הישות העסקית - כלומר המפתח הטבעי) וכל שאר השדות בתוך ה INCLUDE.

הקונבנציה לשם האינדקס היא תמיד "IX_SUPER_INDEX" ....

נשאלת השאלה - מתי זה באמת נכון? (לא הקונבנציה :))

והאם לא עדיף לייצר את הCLUSTERED INDEX על אותו שדה (כמובן עם הוא רציף)?

Answer 1

בוקר טוב,

ראשית, אם  ה- DBA החליט לקרוא לאינדקס super index אז קשה להתווכח איתו...

בכל מקרה, לפי דעתי על מנת שנוכל לענות מה באמת מתאים לסביבה שלך, מציע שתצרף (או שתסביר) קצת על אופי המערכת אצלך.

האם מדובר במערכת עם שאילתות דינמיות (ואז אין לך מושג מה מחפשים מול הטבלה)?
האם באמת מפלטרים וסורקים את כל העמודות וכו'...?

כמו-כן, אם באמת המערכת שלך מאופיינת בסריקות ופילטור רוב העמודות בטבלה כולל פונקציות אנליטיות - מציע לשקול שימוש ביכולות החדשות ב- sql server 2014 כגון: COLUMNSTORE INDEX .

ובמידה ואתה עדיין לא ב- sql server 2014 , אזי מציע לשקול שימוש ב- Indexes with Included .

בהצלחה !!

---

Best Regards,

Itai Binyamin, MVP

www.ItaiBinyamin.Blogspot.com

Answer 2

שלום יוסי,

אני יודע שאני מגיב קצת מאוחר, אבל עדיף מאוחר מאשר אף פעם (נראה לי)...

זה בדרך כלל לא רעיון מאוד חכם ליצור אינדקס כזה. נכון שבמקרים מסוימים הוא יכול לחסוך פעולות Lookup, אבל מצד שני יש לו הרבה חסרונות:

1. הוא תופס הרבה מקום. זה שכפול של כל הטבלה למעשה. אם הטבלה גדולה, אז אתה צריך הרבה מקום בדיסק בשביל לשמור את הטבלה וגם את האינדקס הזה (ומן הסתם אינדקסים נוספים).

2. כל עדכון של עמודה כלשהי בטבלה גורר גם עדכון של האינדקס הזה, כי כל העמודות נמצאות שם. אם יש הרבה עדכונים על הטבלה, אז יהיה הרבה Overhead שנובע מהעדכונים האלה. אם יש עמודות באורך משתנה בטבלה, אז עדכונים של העמודות האלה עלולים גם לגרום ל-Page Splits, מה שמגדיל את ה-Overhead...

3. האינדקס מאוד שמן, וכל סריקה שלו (גם חלקית) גוררת הרבה IO, ולמעשה אין לו שום יתרון לעומת ה-Clustered Index בטבלה לטובת סריקות.

4. צריך כמובן גם לתחזק את האינדקס הזה, כמו כל אינדקס אחר. בהנחה שיש לך תוכנית תחזוקה כלשהי לאינדקסים, האינדקס הזה מאריך ומייקר את תוכנית התחזוקה שלך.

5. אם האינדקס ממוין לפי המפתח, אז הוא אפילו פחות רלוונטי. בדרך כלל שולפים לפי מפתח רשומה אחת בכל פעם ולא טווח של ערכים. אם שולפים רשומה אחת, אז החיסכון של פעולת ה-Lookup הוא יחסית לא משמעותי.

מקווה שעזרתי...

-----------------------------
גיא גלנצר
יועץ ומדריך SQL Server
Madeira - SQL Server Services
http://www.madeirasql.com

Answer 3

תודה גיא,

חיסרונות נוספים מהשטח:

• תחזוקה - עם מוסיפים שדה צריך להוסיף אותו אינדקס - כדי שישאר "SUPPER"...
• DEADLOCKS - בטבלאות שבהם היה גם PK CLUSTERED וגם SUPPER" INDEX" - נגרמו לפעמים DEADLOCKS מכוון ששתי טרנזקציות שלפו ועידכנו במסלולים שונים: טרזקציה אחת לפי ה PK וטרנזקציה שניה לפי הSUPPER - כאשר התבצע העדכון נוצר DEADLOCK (אגב, זה מקור לשאלה נוספת - האם זה הגיוני שיש DEADLOCK רק על אובייקט אחד? - זה מה שראיתי בפועל!)

יוסי

Answer 4

הי יוסי,

Deadlock הוא תמיד בין שניים או יותר Resources שונים. אבל בהחלט יכול להיות Deadlock על אוביקט אחד. לדוגמא, אם יש שני אינדקסים A ו-B על אותה טבלה, ויש שתי טרנזקציות 1 ו-2, כך שטרנזקציה 1 קודם קוראת מאינדקס A ואז קוראת מאינדקס B, ואילו טרנזקציה 2 קודם מעדכנת את אינדקס B ואז מעדכנת את אינדקס A, אז יש לך Deadlock.

-----------------------------
גיא גלנצר
יועץ ומדריך SQL Server
Madeira - SQL Server Services
http://www.madeirasql.com