אינדקס על שדה NVARCHAR

[לושיי]

אינדקס על שדה NVARCHAR

SQL SERVER 2005 יש לי שדה מסוג NVARCHAR(150) שאני מבצע עליו חיפושים רבים ויש בו תווים משפות שונות ומשונות. האם אינדקס מתאים במקרה הזה? האם הוא לא יהיה כבד מדי כאשר מדובר בשדה טקסט?

 

[לושיי]

עוד משהו, מדובר על טבלה כבדה מאוד

היא שוקלת 1.5GB ויש בה קרוב ל - 200,000 רשומות והיא ממשיכה לגדול.

 

[ShlomoBenAri]

תגובה

2005 מאנדקס כל מיני שדות גם בלי לשאול אינדקס זה טוב אבל אם בסינון תשתמש ב LIKE הוא יאבד מיעילותו אם הטבלה שוקלת 1.5GB ויש בה רק 200,000 רשומות משמעו שיש לך הרבה חורים בקובץ - תבצע דחיסה

 

[לושיי]

מה זה חורים בקובץ?

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

 

[חובב טניס]

גם היום חובב טניס ממשיך לטעון את זה../images/Emo13.gif

צריך להבדיל בין ביצוע shrink לקובץ ובין טיפול בפרגמנטציה של טבלה. טיפול בפרגמנטציה בטבלה (ע"י dbcc dbreindex או dbcc indexdefrag) מאד מומלץ. לעומת זאת ביצוע shrink על קובץ הנתונים לא מומלץ.

 

[חובב טניס]

אתה בטוח, שהשרת בונה אינדקסים לבד?

לא ידוע לי על מצב, שבו SQL Server בונה אינדקסים על שדות מיוזמתו. לפי מה שאני מכיר, השרת שומר פרטים על אינדקסים, שלדעתו יכולים להועיל בשאילתות, שניתן לראות אותם בsys.dm_db_missing_index* views. בנוסף השרת בונה מיוזמתו סטטיסטיקות על עמודות בטבלה. יכול להיות, שאתה מתכוון לסטטיסטיקות?

 

[s h i m s h o n]

תלוי

איזה סוג חיפושים אתה מבצע? אם זה בעזרת LIKE עם %123% לדוגמה, אז זה לא מתאים. האם השדה מתאים לאינדקס? כלומר, כמה ערכים דיסטינקטיביים ישנם בו? ומה הפיזור שלהם? אם השדה מתאים והחיפושים בו הם כאלה שיכולים לנצל את האינדקס, אני לא רואה מניעה. בברכה, ש.

 

[לושיי]

הוא נראה מתאים אבל מסתבר שזו עכשיו הבעיה

זו השגיאה שאני מקבל כאשר אני רוצה להוסיף אינדקס: Total size of an index or primary key cannot exceed 900 bytes.

 

[s h i m s h o n]

900 בתים? נשמע מעט

קודם-כל, למה עמודה של 150 תוים תופסת יותר מ-900 בתים (באיזו שפה זה?). לדעתי, אפילו בתצורת UNICODE זה לא אמור להיות כל-כך גדול. הייתי באמת מנסה לגבות את הטבלה, להסיר אותה ולשחזר מגיבוי (או Rebuild אם יש). שנית, האם ב-SQL Server קיים המושג של db-block-size? אם-כן, ייתכן והמגבלה על גודל אינדקס תלוייה בו; כלומר, אם יוגדל ה-db-block-size, תתגמש בהתאם גם המגבלה. צריך לשים לב, ששינוי כזה הוא לא עניין קטן ותלוי בדברים נוספים, למשל בגודל הרשומות ב-DB. אבל לפי המספרים שנתת, הרשומות שלך מאוד גדולות ו-db-block-size גדול יתאים להן. בברכה, ש.

 

[לושיי]

לא יודע לגבי db-block-size

אבל עכשיו באמת בדקתי והרשומה עצמה מוגדרת על 1500 אבל אני יודע שהגבילו אותה ברמת האפליקציה ל - 150. בכל מקרה עכשיו תיקנתי את זה וזה כאן עובד. השאלה היא האם באמת כדאי לי לעשות כאן INDEX? האם אוכל באמצעות הרצת PROFILER לדעת את זה?

 

[חובב טניס]

אתה יכול לבדוק את הquery plan

של השאילתה בmanagement studio ולראות אם נעשה שימוש באינדקס.

 

[לושיי]

אני אשמח אם תוכל להסביר את זה

אני לא ממש יודע להשתמש ב - management studio. איך אני מגיע לזה ואיך אני בודק את הנושא של האינדקס? תודה רבה

 

[לושיי]

OK, נראה לי שזה זה

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

 

[חובב טניס]

פשוט לבדוק

קודם כל אפשר לראות, שכרגע השרת עושה table scan (כלומר עובר על כל הרשומות בטבלה). כאשר אתה רואה שכתוב table scan או clustered index scan תמיד מדובר בtable scan. לרוב רוצים לראות index seek, אבל גם index scan יכול לעזור (ויש כמובן מקרים, שבהם תמיד נראה table scan, גם אם יש אינדקס. זה כמובן אומר, שאינדקס לא עזר לנו). דרך אחת לדעת האם אינדקס יעול היא לבנות את האינדקס ולהריץ מחדש את השאילתה. לבדוק עוד פעם את הquery plan ולראות האם השרת שינה את הquery plan ומשתמש עכשיו באינדקס. שווה לך גם לבדוק את מספר פעולות הIO, שהשרת מבצע עם ובלי האינדקס ע"י הוספת set statistics io on והרצת השאילתה כאשר יש אינדקס וכאשר אין אינדקס והשוואה בין המספרים.

 

[חובב טניס]

900 בתים זאת המגבלה לאינדקסים

לא ניתן לשנות את המגבלה הזאת.