אינדקס - Clustered Index
CREATE UNIQUE CLUSTERED INDEX על שם הטבלה, עם עמודת OrderID במיון עולה. האינדקס יוניק כי orderid חד-ערכי.פרקי ההרצאה: אינדקס - Clustered Index
תמלול ההרצאה: אינדקס - Clustered Index
הטקסט המלא של הדקות הראשונות בהרצאה «אינדקס - Clustered Index» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
הווה ונבחן דוגמה, כרגע אנחנו מדברים על אינדקס מסוג Clustered Index ובואו נראה כיצד אנחנו מייצרים אותו על טבלה וכיצד הוא משפיע על שליפת הנתונים שלי באופן כל כך משמעותי.
אז אנחנו מדברים כרגע על Clustered Index. שימו לב לטבלת Orders, טבלת ההזמנות שנמצאת תחת בסיס נתונים לופמיד. כשאני נכנס תחת שם הטבלה אני פותח כאן, יש לי כאן סקשן שנקרא אינדקסס, כשאני פותח תחת אינדקסס אני בוחן בעצם את רשימת האינדקסים שכבר קיימים לי פר טבלה וכאן אנחנו מגלים כבר משהו שלמדנו אותו בשיעור
הקודם, שיש לנו אוסף של non-clustered index שיכולים להיות הרבה יותר מאחד על עמודות שונות, על חיבור של רצף של עמודות כזה או אחר, אולם לעומת זאת יכול להיות לי רק Clustered Index 1. כאן גם אנחנו יכולים לשים לב שבשעה שאני יוצר פריימרי קי, אוטומטית וברקע נוצר גם בעצם Clustered Index פר טבלה.
יצירת פריימרי קי, משמעותה בעצם ברקע זה יצירת Clustered Index, אינדקס מאוגד עבור אותה עמודה שהיא כרגע פריימרי.
בואו נבחן את הקלאסטרד אינדקס הזה, אני נכנס בפנים ונפתח לי כאן בעצם מסך של האינדקס פרופרטיז על מנת להבין מהם הפרמטרים של אותו אינדקס, ואני מגלה כאן שעבור טבלת orders, עבור אינדקס name pk_orders1 האינדקס הוא מיסוי קלאסטרד והוא יוניק, האינדקס הוא עבור עמודת orderid. כשאנחנו יוצרים אינדקס אנחנו בעצם לוקחים עמודה אחת או יותר,
או רצף של עמודות כשהסדר שלהם בעצם מחייב ואנחנו יוצרים את האינדקס כשאנחנו יוצרים את האינדקס אנחנו גם יכולים לשלוט על סדר המיון על הסורט אורדר אם אני לוקח כאן מספר עמודות ואותם אני רוצה לבנות עליהם אינדקס אני יכול לקבל החלטה האם הסדר של כל עמודה ועמודה בתוך המבנה האינדקסיאלי יהיה הסנדינג או דיסנדינג במקרה הזה לקחנו כאן את orderid ואנחנו רוצים למיין אותו בעצם מהקטן ועד הגדול.
ויש כאן עוד אוסף של מספר אפשרויות בפרמטרים באינדקס עצמו, אנחנו כרגע לא נכנסים לזה. אני רוצה לאבחן כיצד משתנה שליפת נתונים בהתאם לקיומו או אי-קיומו של אינדקס.
איך אנחנו בוחנים זאת? שימו לב, אני רוצה לשלוף כאן נתון מתוך טבלת orders בהינתן תנאי orderid שווה 10248 הזמנה שאותה אני רוצה להציג שימו לב שאני לקחתי כאן בכוונה בworkloads עמודה שהיא מאונדקסת כלומר ברגע שאני שולף לפי עמודה שהיא מאונדקסת הדאטאבס בבחירתו ב-execution pen בתהליך הבאת הנתונים סביר
להניח שיחליט ללכת על אותו אינדקס על מנת לשלוף את הנתונים ביתר יעילות ותחת אשר סריקת כל ה-830 הזמנות הנמצאות בכבודת אורדרס יבחר הדאטאבייס ללכת ולשרוק את האינדקס עם הרבה הרבה פחות נתונים.
בואו נראה זאת, אני שולף והמידע כאן נמצא לפניי אורדר ID 0.5 אני מקבל את המידע אבל יש לי אפשרות לא רק לקבל את הנתונים, אלא לסמן כאן שאני רוצה את ה-estimated execution plan, תביא לי את תוכנית העבודה המשוערכת לשליפת הנתונים, וברגע שאני לוחץ על הכפתור הזה אני לא מקבל את המידע כי הוא פחות חשוב לי, אבל אני מקבל
את מה שאני מבקש כאן שזה בעצם תוכנית הפעולה, תוכנית העברת הנתונים מתוך הדאטאבוס, דרך הפעולה שאותה בחר הדאטאבס על מנת לשלוף לי את הנתונים.
והדרך הזאת מוצגת לפניי על ידי שני רכיבים, קריאתם נעשית מימין לשמאל. מימין לשמאל, וממילא אני קורא את הרכיב הנמצא מצד ימין ראשון, והוא מציין לי Clustered Index Seek.
סרקתי את כל ה-Clustered Index ששמו הוא orders.pk_orders, שזהו אינדקס שנמצא תחת טבלת orders ושמו pk_orders כפי שראינו כאן מצד שמאל של הטבלה בעצם ברשימה שיש לנו כאן אינדקס בשם pk_orders כחלק שנוצר בעקבות בעצם הפריימרי כי סרקנו כאן ושימו לב רצינו להביא נתון אחד
estimated numbers of rows or Executions בעצם שורה שאותה רצינו להביא הבאנו שורה אחת כפי שאתם רואים בדוגמא הזאת אנחנו מביאים כאן את המספר השורה ודבר נוסף מה שאנחנו כאן יכולים לגלות שבעצם כמה זמן ניתן לדאטאבס כמה זמן לקח לדאטאבס על מנת לבצע את הפעולה הזאת כלומר מה היה cost estimated operator cost או estimated io cost
כמה זמן סך הכל לקח לדאטאבס על מנת לסרוק את אותו אינדקס ולהביא לי את הנתונים. בואו ננסה לראות מצב אחר בהיעדר מצב של אינדקס. אני יוצר טבלה מקבילה אחת לאחת From Orders.
שולף טבלה יוצר איזושהי טבלה שהיא אחת לאחת כמו טבלת Orders. מעין לבד העובדה שעל טבלת TempOrders אין עליה כרגע אינדקסים. אני הולך ושולף ממנה נתונים, ושוב לא חשוב לי הבאת הנתונים כמו שחשובה לי דרך הפעולה.
אסטימטד אקוויקיושן פלין, הערכה מה תהיה זה אופן הבאת הנתונים, ברגע שאני לוחץ על זה אני מקבל כאן את הרכיב האחר, אני מקבל כאן טייבל סקאן, סריקת הטבלה במלואה, מה המשמעות?
שימו לב אסטימטד numbers of row, טוב אני לא רשמתי כאן את הכל, לא רשמתי כאן את החלק של ה-worklose זה באמת לא חוכמה, נרשום כאן ונעשה לו קונטרול L, אנחנו עדיין מזהים כמובן שזה טייבל סקן, כיוון שאין לנו כאן אינדקס.
אנחנו מגלים עדיין שהוא היה צריך להביא תורה אחת, אבל שימו לב מה קרה לו כאן מבחינת האופרטור cost, כמה תצרוכת של זמן, עלויות זמן עבודה אנחנו מגלים כאן 0.018. בואו נציין לפנינו את המספר הזה, אופרטור cost.
לעומת זאת, ברגע שאני חוזר לאותה טבלה מאונדקס שאני נמצא בו Work Close עליה ויש לי כאן Clustered Index כשאני לוחץ כאן על ה-Ctrl-L ואני עומד על אותו Clustered Index Seek, מסתכל על הפרמטור של ה-Estimated Operator Cost, אני מגלה שעלויות הזמן שלי, עלויות הפעולה שלי היו ואכן 0.032 קטן משמעותית מהמספר של ה-0.018
פעולה זו הייתה הרבה הרבה יותר מהירה הרבה יותר יעילה