קבלת תובנות לגבי הביצועים של שאילתות

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

ל-BigQuery יש ביצועים טובים מאוד של שאילתות, אבל זו גם מערכת מורכבת ומבוזרת עם הרבה גורמים פנימיים וחיצוניים שיכולים להשפיע על מהירות השאילתות. האופי ההצהרתי של SQL יכול גם להסתיר את המורכבות של ביצוע השאילתה. המשמעות היא שאם השאילתות שלכם פועלות לאט יותר מהצפוי או לאט יותר מהפעולות הקודמות, יכול להיות שיהיה לכם קשה להבין מה קרה.

תרשים ההפעלה של השאילתות מספק ממשק גרפי דינמי לבדיקה של תוכנית השאילתות ופרטי הביצועים שלהן. אפשר לבדוק את תרשים הביצוע של השאילתה לכל שאילתה שפועלת או שהסתיימה.

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

ההרשאות הנדרשות

כדי להשתמש בתרשים של ביצוע השאילתות, צריך לקבל את ההרשאות הבאות:

• bigquery.jobs.get
• bigquery.jobs.listAll

ההרשאות האלה זמינות דרך התפקידים המוגדרים מראש הבאים של ניהול זהויות והרשאות גישה (IAM) ב-BigQuery:

• roles/bigquery.admin
• roles/bigquery.resourceAdmin
• roles/bigquery.resourceEditor
• roles/bigquery.resourceViewer

מבנה של תרשים ביצוע

בתרשים של ביצוע השאילתה מוצג תצוגה גרפית של תוכנית השאילתה במסוף. כל תיבה מייצגת שלב בתוכנית השאילתה, כמו השלבים הבאים:

• קלט: קריאת נתונים מטבלה או בחירת עמודות ספציפיות
• ‫Join (צירוף): מיזוג נתונים משתי טבלאות על סמך התנאי JOIN
• מצטבר: ביצוע חישובים כמו SUM
• מיון: סידור התוצאות

שלבים מורכבים מפעולות שמתארות את הפעולות האישיות שכל עובד מבצע בשלב מסוים. אפשר ללחוץ על שלב כדי לפתוח אותו ולראות את השלבים שלו. השלבים כוללים גם מידע על התזמון היחסי והמוחלט. שמות השלבים מסכמים את הפעולות שהמשתמשים מבצעים. לדוגמה, שלב עם join בשם שלו מציין שהשלב העיקרי בשלב הוא פעולת JOIN. אם שם השלב מסתיים ב-+, המשמעות היא שהשלב כולל שלבים חשובים נוספים. לדוגמה, שלב עם JOIN+ בשם שלו מציין שהשלב מבצע פעולת איחוד ושלבים חשובים אחרים.

הקווים שמחברים בין השלבים מייצגים את חילופי הנתונים הביניים בין השלבים. ‫BigQuery מאחסן את נתוני הביניים בזיכרון של פעולת ה-Shuffle בזמן שהשלבים מבוצעים. המספרים בקצוות מציינים את מספר השורות המשוער שהועברו בין השלבים. מכסת הזיכרון של פעולת ה-Shuffle קשורה למספר המשבצות שהוקצו לחשבון. אם חורגים ממכסת ה-shuffle, הנתונים של ה-shuffle יכולים לעבור לדיסק, והביצועים של השאילתה יואטו באופן משמעותי.

הצגת תובנות לגבי הביצועים של שאילתות

המסוף

כדי לראות תובנות לגבי ביצועי השאילתות:

1. פותחים את הדף BigQuery במסוף Google Cloud .

   לדף BigQuery

2. בחלונית הימנית, לוחצים על כלי הניתוחים:

   

   אם החלונית הימנית לא מוצגת, לוחצים על הרחבת החלונית הימנית כדי לפתוח אותה.

3. בחלונית Explorer לוחצים על Job history.

4. לוחצים על היסטוריה אישית או על היסטוריית הפרויקט.

5. ברשימת המשרות, מזהים את משרת השאילתה שמעניינת אתכם. לוחצים על פעולות ובוחרים באפשרות הצגת המשימה בכלי העריכה.

6. בוחרים בכרטיסייה Execution graph כדי לראות ייצוג גרפי של כל שלב בשאילתה:

   

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

7. לוחצים על שלב כדי לפתוח את חלונית הפרטים של השלב, שבה אפשר לראות את המידע הבא:

   • מידע על תוכנית השאילתה לשלב.
   • השלבים שבוצעו בשלב.
   • תובנות רלוונטיות לגבי הביצועים.

   

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

   

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

   

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

    

11. אופציונלי: כדי לכלול את שלבי ההפצה מחדש של הנתונים בגרף, לוחצים על הצגת שלבי ההפצה מחדש של הנתונים.

    

    אפשר להשתמש באפשרות הזו כדי להציג את שלבי החלוקה מחדש והמיזוג שמוסתרים בתרשים הביצוע שמוצג כברירת מחדל.

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

לכל שאילתה שבה יש בעיות של רגרסיה בביצועים, תובנות לגבי הביצועים מוצגות גם בכרטיסייה Job Information של השאילתה:

SQL

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. מזינים את ההצהרה הבאה בעורך השאילתות:

   SELECT
     `bigquery-public-data`.persistent_udfs.job_url(
       project_id || ':us.' || job_id) AS job_url,
     query_info.performance_insights
   FROM
     `region-REGION_NAME`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
   WHERE
     DATE(creation_time) >= CURRENT_DATE - 30 -- scan 30 days of query history
     AND job_type = 'QUERY'
     AND state = 'DONE'
     AND error_result IS NULL
     AND statement_type != 'SCRIPT'
     AND EXISTS ( -- Only include queries which had performance insights
       SELECT 1
       FROM UNNEST(
         query_info.performance_insights.stage_performance_standalone_insights
       )
       WHERE
         slot_contention
         OR insufficient_shuffle_quota
         OR bi_engine_reasons IS NOT NULL
         OR high_cardinality_joins IS NOT NULL
         OR partition_skew IS NOT NULL
       UNION ALL
       SELECT 1
       FROM UNNEST(
         query_info.performance_insights.stage_performance_change_insights
       )
       WHERE input_data_change.records_read_diff_percentage IS NOT NULL
     );

3. לוחצים על הפעלה.

מידע נוסף על הרצת שאילתות זמין במאמר הרצת שאילתה אינטראקטיבית.

API

כדי לקבל תובנות לגבי ביצועי השאילתות בפורמט לא גרפי, צריך לקרוא לשיטת ה-API‏ jobs.list ולבדוק את המידע שמוחזר JobStatistics2.

הסבר על התובנות לגבי הביצועים של השאילתות

בקטע הזה מוסבר מה המשמעות של תובנות לגבי ביצועים ואיך לטפל בהן.

תובנות לגבי הביצועים מיועדות לשני סוגי קהלים:

• מנתחי נתונים: אתם מריצים שאילתות בפרויקט. אתם רוצים לדעת למה שאילתה שהפעלתם בעבר פועלת לאט יותר מהצפוי, ולקבל טיפים לשיפור הביצועים של שאילתה. יש לכם את ההרשאות שמתוארות בקטע הרשאות נדרשות.

• אדמינים של אגמי נתונים או מחסני נתונים: אתם מנהלים את המשאבים וההזמנות של BigQuery בארגון. יש לכם את ההרשאות שמשויכות לתפקיד אדמין ב-BigQuery.

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

תחרות על משבצות

כשמריצים שאילתה, מערכת BigQuery מנסה לפצל את העבודה שנדרשת בשאילתה למשימות. משימה היא חלק נפרד של נתונים שמוזנים לשלב מסוים ומוצאים ממנו. משבצת אחת בוחרת משימה ומבצעת את פרוסת הנתונים הזו בשלב. באופן אידיאלי, משבצות של BigQuery מבצעות את המשימות האלה במקביל כדי להשיג ביצועים גבוהים. התחרות על משבצות מתרחשת כשיש לשאילתה שלכם הרבה משימות שמוכנות להתחלה, אבל ל-BigQuery אין מספיק משבצות פנויות כדי להריץ אותן.

מה עושים אם אתם אנליסטים

כדי לצמצם את הנתונים שמעובדים בשאילתה, אפשר לפעול לפי ההנחיות במאמר צמצום הנתונים שמעובדים בשאילתות.

מה עושים אם יש לכם הרשאת אדמין

כדי להגדיל את הזמינות של משבצות הזמן או להקטין את השימוש בהן, אפשר לבצע את הפעולות הבאות:

• אם אתם משתמשים בתמחור לפי דרישה של BigQuery, השאילתות שלכם משתמשות במאגר משותף של משבצות זמן. מומלץ לעבור לתמחור ניתוח נתונים על בסיס קיבולת על ידי רכישת הזמנות. הזמנות מאפשרות לכם לשריין משבצות זמן ייעודיות לשאילתות של הארגון.

• אם אתם משתמשים בהזמנות ב-BigQuery, ודאו שיש מספיק משבצות בהזמנה שהוקצתה לפרויקט שבו הופעלה השאילתה. יכול להיות שלא יהיו מספיק מקומות בהזמנה בתרחישים הבאים:

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

  כדי לפתור את הבעיה, אפשר לנסות אחד מהפתרונות הבאים:

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

• מוודאים שהטבלאות שעליהן מריצים את השאילתות הן מקוּבצות. האשכולות עוזרים להבטיח ש-BigQuery יוכל לקרוא במהירות עמודות עם נתונים שקשורים זה לזה.

• מוודאים שהטבלאות שאתם שולחים להן שאילתות מחולקות למחיצות. בטבלאות שלא חולקו למחיצות, BigQuery קורא את כל הטבלה. חלוקת הטבלאות למחיצות עוזרת לוודא שאתם מבצעים שאילתות רק על קבוצת המשנה של הטבלאות שמעניינת אתכם.

מכסת הערבוב לא מספיקה

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

מה עושים אם אתם אנליסטים

בדומה למצב של תחרות על משבצות, צמצום כמות הנתונים שהשאילתה מעבדת עשוי להפחית את השימוש בערבוב. כדי לעשות את זה, פועלים לפי ההנחיות במאמר בנושא הפחתת כמות הנתונים שמעובדים בשאילתות.

פעולות מסוימות ב-SQL נוטות להשתמש בערבוב באופן נרחב יותר, במיוחד פעולות JOIN וסעיפים של GROUP BY. במקרים שבהם הדבר אפשרי, צמצום כמות הנתונים בפעולות האלה עשוי להפחית את השימוש בערבוב.

מה עושים אם יש לכם הרשאת אדמין

כדי לצמצם את התחרות על מכסת ה-shuffle, אפשר לבצע את הפעולות הבאות:

• בדומה למצב של תחרות על משבצות, אם אתם משתמשים בתמחור לפי דרישה של BigQuery, השאילתות שלכם משתמשות במאגר משותף של משבצות. מומלץ לעבור לתמחור ניתוח נתונים על בסיס קיבולת על ידי רכישת הזמנות. הזמנות מאפשרות לכם להקצות משבצות ייעודיות ולשנות את הקיבולת של השאילתות בפרויקטים.

• אם אתם משתמשים בהזמנות של BigQuery, יחידות הקיבולת (Slot) מגיעות עם קיבולת ייעודית לערבוב נתונים. אם בהזמנה מופעלות כמה שאילתות שמשתמשות באופן נרחב בערבוב, יכול להיות ששאילתות אחרות שמופעלות במקביל לא יקבלו מספיק קיבולת ערבוב. כדי לזהות אילו משימות משתמשות בקיבולת של ערבוב נתונים באופן נרחב, אפשר להריץ שאילתה בעמודה period_shuffle_ram_usage_ratio בתצוגה INFORMATION_SCHEMA.JOBS_TIMELINE.

  כדי לפתור את הבעיה, אפשר לנסות אחד או יותר מהפתרונות הבאים:

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

מידע נוסף על פתרון בעיות זמין במאמר שגיאות שקשורות למגבלת הגודל של פעולת ה-Shuffle בדף פתרון הבעיות ב-BigQuery.

שינוי בקנה המידה של קלט הנתונים

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

מה עושים אם אתם אנליסטים

כדי לצמצם את הנתונים שמעובדים בשאילתה, אפשר לפעול לפי ההנחיות במאמר צמצום הנתונים שמעובדים בשאילתות.

שאילתת איחוד בעוצמה גבוהה

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

מה עושים אם אתם אנליסטים

בודקים את תנאי הצירוף כדי לוודא שהגידול בגודל של טבלת הפלט צפוי. לא מומלץ להשתמש ב-cross joins. אם אתם חייבים להשתמש בשאילתת איחוד צולב, נסו להשתמש בסעיף GROUP BY כדי לצבור מראש את התוצאות, או להשתמש בפונקציה אנליטית (window function). מידע נוסף מפורט במאמר בנושא צמצום הנתונים לפני השימוש ב-JOIN.

החלוקה למחיצות לא מאוזנת

גרסת טרום-השקה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

כדי לשלוח משוב או לבקש תמיכה בנוגע לתכונה הזו, אפשר לשלוח אימייל אל [e-mail].

הטיה בהתפלגות הנתונים עלולה לגרום להרצת שאילתות לאט. כשמריצים שאילתה, BigQuery מפצל את הנתונים למחיצות קטנות לעיבוד מקביל. הטיה מתרחשת כשהנתונים לא מחולקים באופן שווה בין המחיצות האלה, לרוב בגלל ערכים שמופיעים לעיתים קרובות במפתחות של הצטרפות או קיבוץ, וכתוצאה מכך חלק מהמחיצות גדולות משמעותית מאחרות. מכיוון שמשבצת אחת מעבדת מחיצה שלמה ולא יכולה לחלוק את העבודה, מחיצה גדולה מדי עלולה להאט את העיבוד, לגרום לשגיאות של חריגה ממכסת המשאבים ובמקרים קיצוניים לגרום לקריסת המשבצת.

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

זיהוי הטיה של מחיצה

משתמשים בכרטיסייה Execution graph ב-BigQuery Studio כדי לגלות באיזה שלב של השאילתה יש הטיה במחיצה. התובנה מסומנת על הבמה. מפרטי השלב אפשר לזהות את החלק הרלוונטי של טקסט השאילתה ואת הטבלאות שעוברות עיבוד. מידע נוסף זמין במאמר בנושא [הסבר על שלבים עם טקסט שאילתה](/bigquery/docs/query-plan-explanation#query_text_heatmap.

דוגמה

השאילתה הבאה מצטרפת לפרטי המאגר עם פרטי הקובץ. הטיה יכולה להתרחש אם בחלק מהמאגרים יש הרבה יותר קבצים מאשר באחרים.

SELECT r.repo_name, COUNT(f.path) AS file_count
FROM `bigquery-public-data.github_repos.sample_repos` AS r
JOIN `bigquery-public-data.github_repos.sample_files` AS f
  ON r.repo_name = f.repo_name
WHERE r.watch_count > 10
GROUP BY r.repo_name

מפתח האיחוד הוא repo_name. בטבלה sample_repos, הערך repo_name אמור להיות ייחודי. לעומת זאת, בטבלה sample_files, יכול להיות ש-repo_name יופיע הרבה פעמים. אם כמה ערכים של repo_name מופיעים בתדירות גבוהה באופן לא פרופורציונלי ב-sample_files, נוצרת חלוקת נתונים לא מאוזנת.

כדי לוודא אם קיימת חלוקת נתונים לא מאוזנת (partition skew), יש לנתח את ההתפלגות של מפתח האיחוד בטבלה הגדולה יותר (sample_files במקרה הזה). מריצים את השאילתה הבאה כדי להעריך את ההתפלגות של repo_name:

SELECT repo_name, COUNT(*) AS occurrences
FROM `bigquery-public-data.github_repos.sample_files`
GROUP BY repo_name
ORDER BY occurrences DESC

בטבלאות גדולות מאוד, אפשר להשתמש בפונקציה APPROX_TOP_COUNT כדי להעריך ביעילות את הערכים הכי נפוצים.

SELECT APPROX_TOP_COUNT(repo_name, 100)
FROM `bigquery-public-data.github_repos.sample_files`

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

איך מצמצמים את ההטיה של המחיצה

אפשר להשתמש בשיטות הבאות כדי לטפל בהטיה של מחיצות:

• מסננים את הנתונים בשלב מוקדם. כדי להפחית את כמות הנתונים שעוברים עיבוד, כדאי להחיל מסננים בשלב מוקדם ככל האפשר בשאילתה. כך אפשר להקטין את מספר השורות שמשויכות למפתחות מוטים לפני שהן מגיעות לפעולות כמו JOIN או GROUP BY.

• פיצול השאילתה כדי לבודד מקשים מוטים. אם ההטיה נגרמת בגלל כמה ערכי מפתח ספציפיים, בדומה לשדה repo_name בדוגמה הקודמת, כדאי לפצל את השאילתה. מעבדים את הנתונים של המפתחות עם ההטיה בנפרד משאר הנתונים, ואז משלבים את התוצאות באמצעות UNION ALL.

  דוגמה: בידוד של מקש שנמצא בשימוש לעיתים קרובות.

  -- Query for the skewed key
  SELECT r.repo_name, COUNT(f.path) AS file_count
  FROM `bigquery-public-data.github_repos.sample_repos` AS r
  JOIN `bigquery-public-data.github_repos.sample_files` AS f
    ON r.repo_name = f.repo_name
  WHERE r.watch_count > 10 AND r.repo_name = 'popular_repo'
  GROUP BY r.repo_name
  
  UNION ALL
  
  -- Query for all other keys
  SELECT r.repo_name, COUNT(f.path) AS file_count
  FROM `bigquery-public-data.github_repos.sample_repos` AS r
  JOIN `bigquery-public-data.github_repos.sample_files` AS f
    ON r.repo_name = f.repo_name
  WHERE r.watch_count > 10 AND r.repo_name != 'popular_repo'
  GROUP BY r.repo_name
  

• טיפול בערכים NULL ובערכי ברירת מחדל: סיבה נפוצה להטיה היא מספר גדול של שורות עם ערכים NULL או מחרוזות ריקות בעמודות מפתח. אם אתם לא צריכים את השורות האלה לניתוח, אתם יכולים לסנן אותן באמצעות פסוקית WHERE לפני JOIN או GROUP BY.

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

• שימוש בפונקציות משוערות: כשמבצעים צבירה של נתונים מוטים, כדאי לשקול אם תוצאה משוערת מקובלת. פונקציות כמו APPROX_COUNT_DISTINCT טולרנטיות יותר לגבי חלוקת נתונים לא מאוזנת מאשר פונקציות מדויקות כמו COUNT(DISTINCT).

הסבר על מידע לגבי שלב השאילתה

בנוסף לשימוש בתובנות לגבי ביצועים של שאילתות, אפשר גם להשתמש בהנחיות הבאות כשבודקים את הפרטים של שלב בשאילתה, כדי להבין אם יש בעיה בשאילתה:

• אם הערך של Wait ms בשלב אחד או יותר גבוה בהשוואה להרצות קודמות של השאילתה:
  • בודקים אם יש מספיק משבצות פנויות כדי להתאים לעומס העבודה. אם לא, כדאי לבצע איזון עומסים כשמריצים שאילתות שדורשות הרבה משאבים, כדי שהן לא יתחרו זו בזו.
  • אם הערך של Wait ms גבוה יותר מאשר בשלב אחד בלבד, כדאי לבדוק את השלב הקודם כדי לראות אם נוצר שם צוואר בקבוק. דברים כמו שינויים משמעותיים בנתונים או בסכימה של הטבלאות שמשתתפות בשאילתה עשויים להשפיע על ביצועי השאילתה.
• אם הערך של Shuffle output bytes בשלב מסוים גבוה בהשוואה להרצות קודמות של השאילתה, או בהשוואה לשלב קודם, כדאי לבדוק את השלבים שבוצעו בשלב הזה כדי לראות אם אחד מהם יוצר כמויות גדולות של נתונים באופן לא צפוי. סיבה נפוצה לכך היא כששלב מעבד INNER JOIN שבו יש מפתחות כפולים משני הצדדים של הצירוף. הפעולה הזו יכולה להחזיר כמות גדולה באופן לא צפוי של נתונים.
• אפשר להשתמש בתרשים הביצוע כדי לראות את השלבים העיקריים לפי משך ועיבוד. כדאי לבדוק את כמות הנתונים שהם מייצרים ואם היא תואמת לגודל הטבלאות שאליהן מתייחסת השאילתה. אם לא, כדאי לעיין בשלבים האלה כדי לראות אם אחד מהם עשוי להפיק כמות בלתי צפויה של נתוני ביניים.

המאמרים הבאים

• כדאי לעיין בהנחיות לאופטימיזציה של שאילתות כדי לקבל טיפים לשיפור ביצועי השאילתות.