אינדקס - Non-clustered Index
CREATE NONCLUSTERED INDEX על CustomerID, ו-INCLUDE (OrderDate) להוספת העמודה. בשיעור האינדקס הקיים נמחק ונוצר מחדש עם ה-INCLUDE.פרקי ההרצאה: אינדקס - Non-clustered Index
תמלול ההרצאה: אינדקס - Non-clustered Index
הטקסט המלא של הדקות הראשונות בהרצאה «אינדקס - Non-clustered Index» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
ובכן, בדוגמה הקודמת ראינו כיצד יצירת Clustered Index על טבלה משפר לי באופן משמעותי את שליפת הנתונים, איני סורק עוד את כל הטבלה ולא את כל האינדקס, אלא אני סורק מספר קטן משמעותית של Pages ומביא מתוכם את הרשימה הספציפית שאותה אני רוצה לראות.
בדוגמה הבאה אני רוצה להציג בפניכם שאילתא נוספת, גם היא מאותה טבלה שזה אחת היצרנו, Select*ChromeTempOrders, אולם הפעם בתוך החלק של ה-Wareclose איני רוצה לשלוף על בסיס עמודת Order ID המאונדקסית, ותחת זאת אני רוצה לשלוף על עמודת Customer ID. עמודה אחרת, עמודה שמציגה לי בעצם את הקוד של הלקוח אשר
ביצע את אותה הזמנה. Customer ID, אני אשרף את זה בעצם על בסיס ערך מסוים, שאותו אני רוצה להציג את כל ההזמנות עבור אותו לקוח.
ב-05 אני מגלה שנשלחו לי כ-6 רשומות לפניי, כשאני נכנס לתוך מסג'ס אני מגלה כאן להפתעתנו את הדבר הבא: לוגיקל ריץ 22 פייג'ס נקראו קאם קאונט סרקתי את כל הטבלה בעצמה על מנת לקבל את הנתונים על מנת להביא לך בעצם את אותן רשומות שקסטומר איי די שלהם שווה בעצם לטום SP. מדוע
הדבר הזה נעשה? כיוון שכרגע שרקנו עמודה שאינה מאינדקסית, ולכן תחת אשר מעבר על כל העמודות, על כל הסריקה של האינדקס בעצמו, שהרי האינדקס בעצמו הוא רור הטבלה, ולכן בעצם סריקה של כל האינדקס בעצמו נותנת לי שליפה רק ברמה של ה-Order AD, מצמצם לי רק אם יש לי Order AD זמין שאותו אני רוצה לשלוף.
אולם אם אני רוצה לשלוף לפי Customer AD, Customer ID זו עמודה שאינה מאונדקסת ולכן לא עוזר לי המיון של האינדקס על בסיס Order ID בשאילתה הזאת אלא אני חייב לעבור על כל האינדקס בעצמו.
בואו נראה זאת כשאני שולט בעצם את ה-Estimated Execution Plan. אני מציג אותו כאן, אנחנו קודם כל מגלים שהוא סורק לי את ה-Clustered Index וזה בסדר גמור כי זו הטבלה עצמה אותה הוא צריך לסרוק אבל הגילוי שאני מגלה אותו כאן בנתון שלפנינו שאומנם אני שולף שורה אחת בלבד, estimated number of executions,
סליחה, estimated numbers of rows. מספר השורות שאותן אני שולף בשליפה כאן יהיו 12. הפעולה הזאת, הרצתי אותה פעם אחת, וזה number of executions.
אבל מה שאנחנו כאן מגלים להפתעתנו זה האופרטור cost, עלויות הפעולה שלי, שאנחנו משווים אותם בעצם למה שהיה לנו לפני יצירת האינדקס.
כשדיברנו על 0.018 עלויות גבוהות, זה גם מה שאנחנו מגיעים כרגע, כי אנחנו בעצם עכשיו משתמשים באינדקס, אבל לא משתמשים במיונה שלו, אנחנו משתמשים באינדקס כי הוא סוף כל סוף גוף ה-storage שאותו אני רוצה, שמחזיק לי את הטבלה שאותו אני סורק, אבל עלויות הפעולה שלי הן מאוד מאוד גבוהות, 0.018 מיליסקונס מבחינת שניות של עבודה,
שזה רחוק ממה שהיה לנו כאן מקודם, שזה היה 0.032 ואולי הרבה הרבה יותר מהירה בשעה שסרקתי אינדקס, אבל סרקתי על בסיס עמידה מאינדקסת.
איך אנחנו נטפל בבעיה הזו ואיך נשפר את השאילתה על מנת שתהיה מהירה ויעילה יותר? אז נכון, גם כאן הפתרון הוא ליצור אינדקס עבור אותה עמודה.
הפעם האינדקס יהיה על עמודת Customer ID. כשאני נכנס כאן, תחת טבלת 10 orders, בואו נרכש את האינדקס הראשון שאותו עשינו, קלאסטרד אינדקס הרי הוא לפנינו.
כשאני לוחץ כאן, קליק עם עניין אינדקסס ניו אינדקסס ניו אינדקס, אני מגלה שהאפשרות של קלאסטרד אינדקס כבר לא enough בלידית מבחינתי, כיוון שוואנס יצרתי קלאסטרד אינדקס אחד, אבל אני יכול ליצור non-clustered index שהוא לא מאוגד אלא צורך לעצמו זיכרון נפרד מהטבלה עבור כל עמודה שאותה אני ארצה non-clustered index אנחנו נציין אותו
על ידי קידומת של סוג הקלאסטר non-clustered index ונגיד לו על איזה עמודה זאת כיוון שכאן אנחנו בונים אותו על עמודת קלסטונר nd זה מה שאני ארשום כאן האם הוא יוניק או לא יוניק לא הוא בוודאי לא יוניק אם אני אנסה לסמן כאן יוניק ואני אבחר את העמודת Customer ID, אני אקבל הודעת שגיאה, כיוון
שהעמודה המופעים ב-Customer ID אינם חד חד ערכיים, שהרי סוף כל סוף Customer ID אחד יכול לבצע מספר זמנות. Index Key column אנחנו מוסיפים את העמודה שאותה עליה אנחנו רוצים לאנדקס Customer ID, איך אני רוצה למיין, ונשפוך סקריפט לתצוגה לתוך ה-Query Editor.
נגיד לו אוקיי, הוא יצר לנו כבר את האינדקס, נוריד כאן את כל המשתנים של ברירת מחדל, ואנחנו מגלים כאן שיצרנו את אותו סקריפט בדיוק ליצירת אינדקס, וכל מה שהשתנה זו המילה הזאת תחת השם clustered, קיבלנו כאן non-clustered יצירת אינדקס נוסף שהוא קיים כרגע בתוך הקבלן.
נסגור את החלון הזה, נסגור גם את החלון הזה. נחזור לתוכנית שלנו, כרגע כבר יש לנו אינדקס, אנחנו כבר יכולים לראות אותו כאן בתוך ה-object explorer-clustered וה-non-clustered-index.
ברגע שאני שולף את הנתון הזה, שבפעם הקודמת, אנחנו זוכרים, נתן לנו 0.018 נאנו סקנד של אופרטור קוסט הרי הוא לפניכם.
בואו נראה מה תהיה עלות הפעולה הפעם. עלות הפעולה שלנו הפעם היא כבר הרבה הרבה יותר מורכבת. אנחנו זוכרים שכשאנחנו קוראים תוכנית פעולה אנחנו קוראים אותה מימין לשמאל ומלמעלה למטה.
שימו לב איך אנחנו עושים זאת. לפני שאנחנו נכנסים כאן אני רק רוצה להציג בפניכם כמה פייג'ס נקראו. total שורות 6. can, can't ו-count, סרקתי את הטבלה פעם אחת, אולם ירדתי משמעותית מבחינת total הפייג'ס שנדרשתי לקרוא תחת השלב 22 page שאותם רציתי לקרוא בסריקת customer ID כאן אנחנו סורקים רק 14. עכשיו אני רוצה להתפנות ל-execution plan,
ctrl+L, estimated execution plan ואנחנו מגלים, אנחנו קוראים את זה, שוב אני מזכיר מימין לשמאל ומלמעלה למטה, כלומר, את הפעולה הראשונה שנעשית זו הפעולה הזאת של האינדקס סקאן. קודם כל אנחנו סורקים בתוך האינדקס סקאן שלנו ה-non-clustered שאותו אנחנו יצרנו את עמודת customer ID. אני ראשית
כל סורק על מנת להביא רק את השורות שבהן יש customer ID. ברגע שהבאתי את אותן שורות הללו, הבאתי כאן מתוך השליפה הזאת שש שורות, כפי שאנחנו רואים כאן בדוגמה הזאת, Estimated Numbers, Numbers of Rows 6, זאת פעולה שתצרוכת ה-Operation שלה היה מאוד מאוד מהיר, כיוון שאנחנו רצים כאן על אינדקס ואנחנו מביאים הרבה הרבה פחות מידי
0.0032. זה הדבר הראשון שאותו אני מביא. אחרי שאני מביא את הנתון הזה אני כבר יכול לרדת כאן ל-Kiluka, מהנתון הזה אני יכול לגשת לרשומות עצמן בתוך הטבלה ומתוך הרשומות עצמן בתוך הטבלה שזה המבנה הטבלאי עצמו כאן אני ניגש כבר לשים רב