‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

נתונים סטטיסטיים של שאילתות

במסמך הזה מוסבר על נתוני השאילתות ש-Spanner מציע כטבלאות מובנות. אפשר לאחזר נתונים סטטיסטיים מטבלאות SPANNER_SYS.QUERY_STATS* באמצעות הצהרות SQL.

מתי כדאי להשתמש בנתוני סטטיסטיקה של שאילתות

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

איך ניגשים לסטטיסטיקות של שאילתות

‫Spanner מספק את נתוני השאילתות בסכימה SPANNER_SYS. אפשר לגשת לנתוני SPANNER_SYS בדרכים הבאות:

הדף Spanner Studio של מסד נתונים במסוף Google Cloud .
הפקודה gcloud spanner databases execute-sql.
מרכז הבקרה תובנות לגבי שאילתות.
השיטה executeSql או השיטה executeStreamingSql.

ה-methods הבאות לקריאה יחידה ש-Spanner מספק לא תומכות ב-SPANNER_SYS:

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

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

שימוש במעבד (CPU) לפי שאילתה

בטבלאות הבאות אפשר לעקוב אחרי השאילתות עם השימוש הכי גבוה ב-CPU במהלך תקופת זמן מסוימת:

‫SPANNER_SYS.QUERY_STATS_TOP_MINUTE: שאילתות במהלך אינטרוולים של דקה אחת
‫SPANNER_SYS.QUERY_STATS_TOP_10MINUTE: שאילתות במהלך אינטרוולים של 10 דקות
‫SPANNER_SYS.QUERY_STATS_TOP_HOUR: שאילתות במהלך אינטרוולים של שעה

המאפיינים של הטבלאות האלה:

כל טבלה מכילה נתונים של מרווחי זמן לא חופפים, בהתאם למשך הזמן שצוין בשם הטבלה.
המרווחים מבוססים על שעות
- מרווחי זמן של דקה מסתיימים בדיוק בדקה.
- מרווחים של 10 דקות מסתיימים כל 10 דקות החל מתחילת השעה.
- מרווחים של שעה מסתיימים בתחילת השעה.
לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL הם:
- דקה אחת: 11:58:00 עד 11:58:59
- ‫10 דקות: 11:40:00–11:49:59
- שעה אחת: 10:00:00–10:59:59 AM
מערכת Spanner מקבצת את הנתונים הסטטיסטיים לפי הטקסט של שאילתת ה-SQL. אם בשאילתה נעשה שימוש בפרמטרים של שאילתות,‏ Spanner מקבץ את כל ההפעלות של השאילתה הזו בשורה אחת. אם השאילתה משתמשת במחרוזות מילוליות, Spanner מקבץ את הנתונים הסטטיסטיים רק אם טקסט השאילתה המלא זהה. אם יש הבדל כלשהו בטקסט, כל שאילתה מופיעה כשורה נפרדת. ב-DML של קבוצות, מערכת Spanner מבצעת נורמליזציה של הקבוצה על ידי הסרת כפילויות של הצהרות זהות רצופות לפני יצירת טביעת האצבע.
אם יש תג בקשה, TEXT_FINGERPRINT הוא הגיבוב של תג הבקשה. אחרת, זה הגיבוב של הערך TEXT. בפקודות DML עם חלוקה למחיצות, הערך של TEXT_FINGERPRINT הוא תמיד הגיבוב של הערך TEXT.
כל שורה מכילה נתונים סטטיסטיים של כל ההרצות של שאילתת SQL מסוימת, ש-Spanner אוסף לגביה נתונים סטטיסטיים במהלך המרווח שצוין.
אם Spanner לא מצליח לאחסן את כל השאילתות שהופעלו במהלך המרווח, המערכת נותנת עדיפות לשאילתות עם השימוש הכי גבוה במעבד במהלך המרווח שצוין.
השאילתות שעוקבים אחריהן כוללות שאילתות שהושלמו, שאילתות שנכשלו או שאילתות שהמשתמש ביטל.
קבוצת משנה של נתונים סטטיסטיים ספציפית לשאילתות שהופעלו אבל לא הושלמו:
- מספר הביצועים וחביון ממוצע בשניות בכל השאילתות שלא הצליחו.
- מספר ההרצות של שאילתות שהזמן הקצוב לתפוגה שלהן הסתיים.
- מספר ההרצות של שאילתות שבוטלו על ידי המשתמש או שנכשלו בגלל בעיות בקישוריות לרשת.
כל העמודות בטבלאות הן nullable.

לנתונים הסטטיסטיים של שאילתות לגבי פקודות partitioned DML שהופעלו בעבר יש את המאפיינים הבאים:

כל פקודת DML מחולקת שמופעלת בהצלחה נחשבת להרצה אחת. לפקודת DML עם חלוקה למחיצות שנכשלה, בוטלה או נמצאת בתהליך הרצה יש ספירת הרצה של אפס.
לא מתבצע מעקב אחרי נתונים סטטיסטיים של פקודות DML עם חלוקה למחיצות.ALL_FAILED_EXECUTION_COUNTALL_FAILED_AVG_LATENCY_SECONDSCANCELLED_OR_DISCONNECTED_EXECUTION_COUNTTIMED_OUT_EXECUTION_COUNT
הנתונים הסטטיסטיים של כל פקודת DML עם חלוקה למחיצות שהופעלה בעבר עשויים להופיע במרווחי זמן שונים. המדדים SPANNER_SYS.QUERY_STATS_TOP_10MINUTE ו-SPANNER_SYS.QUERY_STATS_TOP_HOUR מספקים תצוגה מצטברת של הצהרות DML מחולקות שמושלמות תוך 10 דקות ושעה, בהתאמה. כדי לראות נתונים סטטיסטיים של הצהרות שהמשך שלהן ארוך משעה אחת, אפשר לעיין בדוגמה לשאילתה.

סכמת טבלאות

שם עמודה	סוג	תיאור
`INTERVAL_END`	`TIMESTAMP`	סוף מרווח הזמן שבו התרחשו ההרצות של השאילתות הכלולות.
`REQUEST_TAG`	`STRING`	תג הבקשה האופציונלי לפעולת השאילתה הזו. מידע נוסף על השימוש בתגי בקשות זמין במאמר פתרון בעיות באמצעות תגי בקשות.
`QUERY_TYPE`	`STRING`	מציין אם שאילתה היא `PARTITIONED_QUERY` או `QUERY`. ‫`PARTITIONED_QUERY` היא שאילתה עם `partitionToken` שהתקבלה מ-`PartitionQuery` API, או הצהרת partitioned DML. כל השאילתות והצהרות ה-DML האחרות מסומנות בסוג השאילתה `QUERY`.
`TEXT`	`STRING`	טקסט של שאילתת SQL, קטום לכ-64KB. הנתונים הסטטיסטיים של כמה שאילתות עם אותו מחרוזת תגים מקובצים בשורה אחת עם `REQUEST_TAG`התאמה לאותה מחרוזת תגים. רק הטקסט של אחת מהשאילתות האלה מוצג בשדה הזה, והוא נחתך לכ-64KB. ב-DML של קבוצות, קבוצת הצהרות ה-SQL משוטחת לשורה אחת, והן מחוברות באמצעות נקודה ופסיק כמפריד. טקסטים זהים רצופים של SQL מוסרים לפני החיתוך.
`TEXT_TRUNCATED`	`BOOL`	האם הטקסט של השאילתה נחתך.
`TEXT_FINGERPRINT`	`INT64`	הגיבוב של הערך `REQUEST_TAG` אם הוא קיים, אחרת הגיבוב של הערך `TEXT`. מתייחס לשדה `query_fingerprint` ביומן הביקורת
`EXECUTION_COUNT`	`INT64`	מספר הפעמים ש-Spanner ראה את השאילתה במהלך המרווח.
`AVG_LATENCY_SECONDS`	`FLOAT64`	משך הזמן הממוצע בשניות של כל ביצוע שאילתה במסד הנתונים. הזמן הממוצע הזה לא כולל את זמן הקידוד והשידור של קבוצת התוצאות, וגם לא את התקורה.
`AVG_ROWS`	`FLOAT64`	המספר הממוצע של השורות שהשאילתה החזירה.
`AVG_BYTES`	`FLOAT64`	מספר הבייטים הממוצע של נתונים שהשאילתה החזירה, לא כולל תקורה של קידוד שידור.
`AVG_ROWS_SCANNED`	`FLOAT64`	מספר השורות הממוצע שנסרקו על ידי השאילתה, לא כולל ערכים שנמחקו.
`AVG_CPU_SECONDS`	`FLOAT64`	המספר הממוצע של שניות של זמן מעבד ש-Spanner השקיע בכל הפעולות כדי להריץ את השאילתה.
`ALL_FAILED_EXECUTION_COUNT`	`INT64`	מספר הפעמים שהשאילתה נכשלה במהלך המרווח.
`ALL_FAILED_AVG_LATENCY_SECONDS`	`FLOAT64`	משך הזמן הממוצע בשניות של כל ביצוע שאילתה שנכשל במסד הנתונים. הזמן הממוצע הזה לא כולל את הזמן של קידוד ושידור של מערך התוצאות, וגם לא את התקורה.
`CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT`	`INT64`	מספר הפעמים שהשאילתה בוטלה על ידי המשתמש או נכשלה בגלל חיבור רשת לא תקין במהלך המרווח.
`TIMED_OUT_EXECUTION_COUNT`	`INT64`	מספר הפעמים שחלף הזמן הקצוב לשאילתה במהלך המרווח.
`AVG_BYTES_WRITTEN`	`FLOAT64`	המספר הממוצע של בייטים שנכתבו על ידי ההצהרה.
`AVG_ROWS_WRITTEN`	`FLOAT64`	המספר הממוצע של שורות ששונו על ידי ההצהרה.
`STATEMENT_COUNT`	`INT64`	סכום ההצהרות שמצטברות ברשומה הזו. בשביל שאילתות רגילות ו-DML, הערך הזה שווה למספר ההרצות. ב-DML של אצוות, מערכת Spanner מתעדת את מספר ההצהרות באצווה.
`RUN_IN_RW_TRANSACTION_EXECUTION_COUNT`	`INT64`	מספר הפעמים שהשאילתה הופעלה כחלק מטרנזקציית קריאה-כתיבה. העמודה הזו עוזרת לכם לקבוע אם אפשר להימנע ממחלוקות על נעילה על ידי העברת השאילתה לעסקה לקריאה בלבד.
`LATENCY_DISTRIBUTION`	`ARRAY<STRUCT>`	היסטוגרמה של זמן ביצוע השאילתה. הערכים נמדדים בשניות. הערה לגבי הממשק של PostgreSQL: מסדי נתונים בניב PostgreSQL לא תומכים בעמודה הזו. במקום זאת, משתמשים בעמודה `LATENCY_DISTRIBUTION_JSON_STRING` במסדי נתונים של ניב PostgreSQL. המערך מכיל רכיב יחיד והוא מהסוג הבא: `ARRAY<STRUCT< COUNT INT64, MEAN FLOAT64, SUM_OF_SQUARED_DEVIATION FLOAT64, NUM_FINITE_BUCKETS INT64, GROWTH_FACTOR FLOAT64, SCALE FLOAT64, BUCKET_COUNTS ARRAY<INT64>>>` מידע נוסף על הערכים מופיע במאמרים התפלגות ואקספוננציאלי. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64)`, שמחזירה את האחוזון המשוער n. דוגמה קשורה מופיעה במאמר בנושא חיפוש חביון באחוזון ה-99 של שאילתות. מידע נוסף זמין במאמר בנושא אחוזונים ומדדים עם ערכי התפלגות.
`AVG_MEMORY_PEAK_USAGE_BYTES`	`FLOAT64`	במהלך הרצת שאילתה מבוזרת, ממוצע השימוש בזיכרון בשיא (בבייטים). אפשר להשתמש בנתון הסטטיסטי הזה כדי לזהות אילו שאילתות או גדלים של נתוני טבלה עלולים להיתקל במגבלות זיכרון.
`AVG_MEMORY_USAGE_PERCENTAGE`	`FLOAT64`	במהלך ביצוע שאילתה מבוזרת, השימוש הממוצע בזיכרון שנדרש (כאחוז ממגבלת הזיכרון שמותרת לשאילתה הזו). הנתון הסטטיסטי הזה עוקב רק אחרי הזיכרון שנדרש להרצת השאילתה. חלק מהמפעילים משתמשים בזיכרון נוסף של מאגר זמני כדי לשפר את הביצועים. הזיכרון הנוסף שמשמש לחיץ זמני מוצג בתוכנית השאילתה, אבל לא משמש לחישוב `AVG_MEMORY_USAGE_PERCENTAGE` כי הזיכרון שמשמש לחיץ זמני משמש לאופטימיזציה ולא נדרש. אפשר להשתמש בנתון הזה כדי לזהות שאילתות שמתקרבות למגבלת השימוש בזיכרון, ועלולות להיכשל אם גודל הנתונים יגדל. כדי לצמצם את הסיכון לכשל בשאילתה, כדאי לעיין בשיטות המומלצות ל-SQL כדי לבצע אופטימיזציה של השאילתות האלה, או לפצל את השאילתה לחלקים שקוראים פחות נתונים.
`AVG_QUERY_PLAN_CREATION_TIME_SECS`	`FLOAT64`	זמן המעבד הממוצע בשניות שהושקע בהידור השאילתה, כולל יצירת זמן הריצה של השאילתה. אם הערך בעמודה הזו גבוה, כדאי להשתמש בשאילתות עם פרמטרים.
`AVG_FILESYSTEM_DELAY_SECS`	`FLOAT64`	הזמן הממוצע שבו השאילתה מבלה בקריאה ממערכת הקבצים או בחסימה של קלט/פלט (I/O). אפשר להשתמש בנתון הסטטיסטי הזה כדי לזהות פוטנציאל לזמן אחזור גבוה שנגרם בגלל קלט/פלט של מערכת קבצים. כדי לצמצם את הבעיה, מוסיפים אינדקס או מוסיפים פסקה `STORING` (GoogleSQL) או `INCLUDE` (PostgreSQL) לאינדקס קיים.
`AVG_REMOTE_SERVER_CALLS`	`FLOAT64`	המספר הממוצע של קריאות לשרת מרוחק (RPC) שהושלמו על ידי השאילתה. אפשר להשתמש בנתון הסטטיסטי הזה כדי לזהות אם לשאילתות שונות שסורקות את אותו מספר שורות יש מספר שונה מאוד של קריאות RPC. יכול להיות שיועיל להוסיף אינדקס לשאילתה עם ערך RPC גבוה יותר, או להוסיף לה פסקה של `STORING` (GoogleSQL) או `INCLUDE` (PostgreSQL) לאינדקס קיים.
`AVG_ROWS_SPOOLED`	`FLOAT64`	המספר הממוצע של שורות שנכתבו לדיסק זמני (לא בזיכרון) על ידי הצהרת השאילתה. אפשר להשתמש בנתון הסטטיסטי הזה כדי לזהות שאילתות עם פוטנציאל לחביון גבוה, שדורשות הרבה זיכרון ולא ניתן להריץ אותן בזיכרון. כדי לצמצם את הסיכון, אפשר לשנות את הסדר של `JOIN` או להוסיף אינדקס שמספק את `SORT` הנדרש.
`AVG_DISK_IO_COST`	`FLOAT64`	העלות הממוצעת של השאילתה הזו במונחים של Spanner HDD disk load. אפשר להשתמש בערך הזה כדי להשוות בין עלויות קלט/פלט של קריאות בכונן קשיח שמופעלות במסד הנתונים. הפעלת שאילתות על נתונים באחסון HDD כרוכה בתשלום על קיבולת טעינת הדיסק של ה-HDD של המופע. ערך גבוה יותר מציין שאתם משתמשים בעומס דיסק HDD גדול יותר, והשאילתה עשויה לפעול לאט יותר מאשר אם היא הייתה פועלת ב-SSD. בנוסף, אם העומס על דיסק ה-HDD שלכם הוא בקיבולת מלאה, יכול להיות שהביצועים של השאילתות שלכם ייפגעו עוד יותר. אתם יכולים לעקוב אחרי הקיבולת הכוללת של עומס הדיסק של ה-HDD של המופע כאחוז. כדי להוסיף עוד קיבולת עומס של דיסק HDD, אפשר להוסיף עוד יחידות עיבוד או צמתים למופע. מידע נוסף זמין במאמר שינוי קיבולת המחשוב. כדי לשפר את ביצועי השאילתות, כדאי גם להעביר חלק מהנתונים ל-SSD. עבור עומסי עבודה שצורכים הרבה קלט/פלט בדיסק, מומלץ לאחסן נתונים שניגשים אליהם לעיתים קרובות באחסון SSD. הגישה לנתונים מכונן SSD לא צורכת את קיבולת הטעינה של דיסק HDD. אפשר לאחסן טבלאות, עמודות או אינדקסים משניים נבחרים באחסון SSD לפי הצורך, תוך שמירה של נתונים שניגשים אליהם לעיתים רחוקות באחסון HDD. מידע נוסף זמין במאמר סקירה כללית על אחסון בשכבות.
`LATENCY_DISTRIBUTION_JSON_STRING`	`STRING`	היסטוגרמה של זמן ביצוע השאילתה. הערכים נמדדים בשניות. ייצוג מחרוזת תואמת JSON של נתון הסטטיסטיקה `LATENCY_DISTRIBUTION`. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו ה-STRUCT שמוגדר בעמודה `LATENCY_DISTRIBUTION`. העמודה הזו נתמכת במסדי נתונים של ניב GoogleSQL וניב PostgreSQL. בעמודה הזו מופיע הפיזור. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64)`, שמחזירה את האחוזון המשוער n. דוגמה קשורה מופיעה במאמר חיפוש השאילתות עם זמן האחזור באחוזון ה-99 באמצעות העמודה `LATENCY_DISTRIBUTION_JSON_STRING`. מידע נוסף זמין במאמר אחוזונים ומדדים של ערכי התפלגות.
`QUERY_OPTIMIZER_VERSIONS`	`ARRAY<INT64>`	הגרסאות של הכלי לאופטימיזציה של שאילתות ששימשו לשאילתות בחלון הזמן הזה.
`STATISTICS_PACKAGE_NAMES`	`ARRAY<STRING>`	השמות של חבילות הנתונים הסטטיסטיים שמשמשות לשאילתות בחלון הזמן הזה.

EXECUTION_COUNT, ‏ AVG_LATENCY_SECONDS, ‏ LATENCY_DISTRIBUTION ו-LATENCY_DISTRIBUTION_JSON_STRING. שאילתות שנכשלו כוללות שאילתות שנכשלו בגלל תחביר שגוי או שנתקלו בשגיאה זמנית, אבל הצליחו בניסיון חוזר. הנתונים הסטטיסטיים האלה לא כוללים פקודות DML עם חלוקה למחיצות שנכשלו או בוטלו.

נתונים סטטיסטיים מצטברים

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

‫SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: שאילתות במהלך אינטרוולים של דקה אחת
‫SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: שאילתות במהלך אינטרוולים של 10 דקות
‫SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: שאילתות במהלך אינטרוולים של שעה

המאפיינים של הטבלאות האלה:

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

לדוגמה, בשעה 11:59:30, המרווחים האחרונים שזמינים לשאילתות SQL הם:
- דקה אחת: 11:58:00 עד 11:58:59
- ‫10 דקות: 11:40:00–11:49:59
- שעה אחת: 10:00:00–10:59:59 AM
כל שורה מכילה נתונים סטטיסטיים של כל השאילתות שהופעלו במסד הנתונים במהלך המרווח שצוין, אחרי צבירה. יש רק שורה אחת לכל מרווח זמן, והיא כוללת שאילתות שהושלמו, שאילתות שנכשלו ושאילתות שהמשתמש ביטל.
הנתונים הסטטיסטיים שנאספים בטבלאות TOTAL עשויים לכלול שאילתות שלא נאספו בטבלאות TOP ב-Spanner.
חלק מהעמודות בטבלאות האלה מוצגות כמדדים ב-Cloud Monitoring. אלה המדדים שמוצגים:
- מספר הפעמים שהשאילתה הופעלה
- כשלים בשאילתות
- זמני האחזור של השאילתות
- מספר השורות שהוחזרו
- מספר השורות שנסרקו
- מספר הבייטים שהוחזרו
- זמן CPU (מעבד) של השאילתה
מידע נוסף מופיע במאמר בנושא מדדים של Spanner.

סכמת טבלאות

שם עמודה	סוג	תיאור
`INTERVAL_END`	`TIMESTAMP`	סוף מרווח הזמן שבו התרחשו ההרצות של השאילתות הכלולות.
`EXECUTION_COUNT`	`INT64`	מספר הפעמים ש-Spanner ראה את השאילתה במהלך פרק הזמן.
`AVG_LATENCY_SECONDS`	`FLOAT64`	משך הזמן הממוצע בשניות של כל ביצוע שאילתה במסד הנתונים. הזמן הממוצע הזה לא כולל את זמן הקידוד והשידור של קבוצת התוצאות, וגם לא את התקורה.
`AVG_ROWS`	`FLOAT64`	המספר הממוצע של השורות שהשאילתה החזירה.
`AVG_BYTES`	`FLOAT64`	מספר הבייטים הממוצע של נתונים שהשאילתה החזירה, לא כולל תקורה של קידוד שידור.
`AVG_ROWS_SCANNED`	`FLOAT64`	מספר השורות הממוצע שנסרקו על ידי השאילתה, לא כולל ערכים שנמחקו.
`AVG_CPU_SECONDS`	`FLOAT64`	המספר הממוצע של שניות של זמן מעבד ש-Spanner השקיע בכל הפעולות כדי להריץ את השאילתה.
`ALL_FAILED_EXECUTION_COUNT`	`INT64`	מספר הפעמים שהשאילתה נכשלה במהלך המרווח.
`ALL_FAILED_AVG_LATENCY_SECONDS`	`FLOAT64`	משך הזמן הממוצע בשניות של כל ביצוע שאילתה שנכשל במסד הנתונים. הזמן הממוצע הזה לא כולל את הזמן של קידוד ושידור של מערך התוצאות, וגם לא את התקורה.
`CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT`	`INT64`	מספר הפעמים שהשאילתה בוטלה על ידי המשתמש או נכשלה בגלל חיבור רשת לא תקין במהלך המרווח.
`TIMED_OUT_EXECUTION_COUNT`	`INT64`	מספר הפעמים שחלף הזמן הקצוב לשאילתה במהלך המרווח.
`AVG_BYTES_WRITTEN`	`FLOAT64`	המספר הממוצע של בייטים שנכתבו על ידי ההצהרה.
`AVG_ROWS_WRITTEN`	`FLOAT64`	המספר הממוצע של שורות ששונו על ידי ההצהרה.
`RUN_IN_RW_TRANSACTION_EXECUTION_COUNT`	`INT64`	מספר הפעמים שהשאילתות הופעלו כחלק מטרנזקציות של קריאה וכתיבה. העמודה הזו עוזרת לכם להחליט אם אפשר להימנע ממחלוקות על נעילה על ידי העברה של חלק מהשאילתות לעסקאות לקריאה בלבד.
`LATENCY_DISTRIBUTION`	`ARRAY<STRUCT>`	היסטוגרמה של זמן הביצוע בשאילתות. הערכים נמדדים בשניות. הערה לגבי הממשק של PostgreSQL: מסדי נתונים בניב PostgreSQL לא תומכים בעמודה הזו. במקום זאת, משתמשים בעמודה `LATENCY_DISTRIBUTION_JSON_STRING` במסדי נתונים של ניב PostgreSQL. מציינים את המערך באופן הבא: `ARRAY<STRUCT< COUNT INT64, MEAN FLOAT64, SUM_OF_SQUARED_DEVIATION FLOAT64, NUM_FINITE_BUCKETS INT64, GROWTH_FACTOR FLOAT64, SCALE FLOAT64, BUCKET_COUNTS ARRAY<INT64>>>` מידע נוסף על הערכים זמין במאמרים בנושא התפלגות ואקספוננציאלי. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64)`, שמחזירה את האחוזון המשוער n. דוגמה קשורה מופיעה במאמר בנושא חיפוש חביון באחוזון ה-99 של שאילתות. מידע נוסף זמין במאמר בנושא אחוזונים ומדדים עם ערכי התפלגות.
`LATENCY_DISTRIBUTION_JSON_STRING`	`STRING`	היסטוגרמה של זמן ביצוע השאילתה. הערכים נמדדים בשניות. ייצוג מחרוזת תואמת ל-JSON של נתון הסטטיסטיקה `LATENCY_DISTRIBUTION`. מחרוזת ה-JSON היא אובייקט JSON עם אותו מבנה כמו ה-STRUCT שמוגדר בעמודה `LATENCY_DISTRIBUTION`. העמודה הזו נתמכת במסדי נתונים של ניב GoogleSQL וניב PostgreSQL. בעמודה הזו מופיע הפיזור. כדי לחשב את חביון האחוזון מההתפלגות, משתמשים בפונקציה `SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64)`, שמחזירה את האחוזון המשוער n. דוגמה קשורה מופיעה במאמר חיפוש השאילתות עם זמן האחזור באחוזון ה-99 באמצעות העמודה `LATENCY_DISTRIBUTION_JSON_STRING`. מידע נוסף זמין במאמר אחוזונים ומדדים של ערכי התפלגות.

שמירת נתונים

לפחות, Spanner שומר נתונים לכל טבלה למשך תקופות הזמן הבאות:

‫SPANNER_SYS.QUERY_STATS_TOP_MINUTE ו-SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE: מרווחי זמן שכוללים את 6 השעות האחרונות.
‫SPANNER_SYS.QUERY_STATS_TOP_10MINUTE ו-SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE: מרווחי זמן שכוללים את 4 הימים הקודמים.
‫SPANNER_SYS.QUERY_STATS_TOP_HOUR ו-SPANNER_SYS.QUERY_STATS_TOTAL_HOUR: מרווחי זמן שכוללים את 30 הימים האחרונים.

שאילתות לדוגמה

בקטע הזה מופיעות כמה דוגמאות להצהרות SQL שמאחזרות נתונים סטטיסטיים של שאילתות. אפשר להריץ את הצהרות ה-SQL האלה באמצעות ספריות הלקוח, Google Cloud CLI או מסוףGoogle Cloud .

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

השאילתה הבאה מחזירה את הנתונים הגולמיים של השאילתות המובילות בדקה הקודמת:

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
ORDER BY interval_end DESC;

הצגת נתונים סטטיסטיים של פקודות DML עם חלוקה למחיצות שפועלות יותר משעה

השאילתה הבאה מחזירה את מספר ההרצות ואת מספר השורות הממוצע שנכתבו על ידי שאילתות ה-DML המחיצות המובילות בשעות הקודמות:

SELECT text,
       request_tag,
       interval_end,
       sum(execution_count) as execution_count,
       sum(avg_rows_written*execution_count)/sum(execution_count) as avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE starts_with(text, "UPDATE") AND query_type = "PARTITIONED_QUERY"
group by text, request_tag, interval_end
ORDER BY interval_end DESC;

תכין רשימה של השאילתות עם השימוש הכי גבוה ב-CPU

השאילתה הבאה מחזירה את השאילתות עם השימוש הכי גבוה ב-CPU בשעה הקודמת:

SELECT text,
       request_tag,
       execution_count AS count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY total_cpu DESC;

חיפוש המספר הכולל של ההפעלות בתקופה נתונה

השאילתה הבאה מחזירה את המספר הכולל של שאילתות שהופעלו במרווח הזמן המלא האחרון של דקה אחת:

SELECT interval_end,
       execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_minute);

מציאת זמן האחזור הממוצע של שאילתה

השאילתה הבאה מחזירה את נתוני זמן האחזור הממוצע של שאילתה ספציפית:

SELECT avg_latency_seconds
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "SELECT x FROM table WHERE x=@foo;";

מציאת חביון האחוזון ה-99 של שאילתות

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

השאילתות הבאות מחזירות את האחוזון ה-99 של זמן הביצוע של שאילתות שהופעלו ב-10 הדקות האחרונות.

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

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

במסדי נתונים של ניב PostgreSQL, משתמשים בעמודה LATENCY_DISTRIBUTION_JSON_STRING במקום זאת:

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

איתור השאילתות שסורקות הכי הרבה נתונים

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

SELECT text,
       execution_count,
       avg_rows_scanned
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_scanned DESC;

איתור ההצהרות שכתבו הכי הרבה נתונים

אפשר להשתמש במספר השורות שנכתבו (או בבייטים שנכתבו) על ידי DML כמדד לכמות הנתונים ששונו על ידי השאילתה. השאילתה הבאה מחזירה את מספר השורות שנכתבו על ידי הצהרות DML שהופעלו בשעה הקודמת:

SELECT text,
       execution_count,
       avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_written DESC;

סיכום השימוש במעבד בכל השאילתות

השאילתה הבאה מחזירה את מספר שעות השימוש במעבד בשעה הקודמת:

SELECT (avg_cpu_seconds * execution_count / 60 / 60)
  AS total_cpu_hours
FROM spanner_sys.query_stats_total_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_hour);

רשימת השאילתות שנכשלו בתקופת זמן נתונה

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

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       all_failed_execution_count,
       all_failed_avg_latency_seconds,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;

חיפוש המספר הכולל של השגיאות בתקופה מסוימת

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

SELECT interval_end,
       all_failed_execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_minute)
ORDER BY interval_end;

רשימת השאילתות שפג הזמן הקצוב לתפוגה שלהן הכי הרבה פעמים

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

SELECT text,
       execution_count AS count,
       timed_out_execution_count AS timeout_count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY timed_out_execution_count DESC;

איך מוצאים את זמן האחזור הממוצע של ביצועים מוצלחים ושל ביצועים שנכשלו בשאילתה

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

SELECT avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text LIKE "select x from table where x=@foo;";

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

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

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

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

בחירת תקופת זמן לבדיקה

כדי להתחיל את החקירה, צריך לחפש מועד שבו החלה באפליקציה צריכת CPU גבוהה. לדוגמה, אם הבעיה התחילה להתרחש בערך ב-17:00 ב-24 ביולי 2020 (שעון UTC).

איסוף נתונים סטטיסטיים של שאילתות לתקופת הזמן שנבחרה

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

השאילתה הבאה מחזירה את הנתונים הסטטיסטיים המצטברים של השאילתות מ-16:30 עד 17:30 UTC כולל. השאילתה משתמשת ב-ROUND כדי להגביל את מספר המקומות העשרוניים למטרות הצגה.

SELECT interval_end,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_rows,2) AS rows_returned,
       ROUND(avg_bytes,2) AS bytes,
       ROUND(avg_rows_scanned,2) AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS avg_cpu
FROM spanner_sys.query_stats_total_10minute
WHERE
  interval_end >= "2020-07-24T16:30:00Z"
  AND interval_end <= "2020-07-24T17:30:00Z"
ORDER BY interval_end;

הפעלת השאילתה הניבה את התוצאות הבאות.

interval_end	ספירה	זמן טעינה	rows_returned	בייטים	rows_scanned	avg_cpu
2020-07-24T16:30:00Z	6	0.06	5.00	536.00	16.67	0.035
2020-07-24T16:40:00Z	55	0.02	‫0.22	25.29	‫0.22	0.004
2020-07-24T16:50:00Z	102	0.02	0.30	33.35	0.30	0.004
`2020-07-24T17:00:00Z`	`154`	`1.06`	`4.42`	`486.33`	`7792208.12`	`4.633`
2020-07-24T17:10:00Z	94	0.02	1.68	106.84	1.68	0.006
2020-07-24T17:20:00Z	110	0.02	0.38	34.60	0.38	0.005
2020-07-24T17:30:00Z	47	0.02	0.23	24.96	0.23	0.004

בטבלה שלמעלה אפשר לראות שזמן ה-CPU הממוצע, העמודה avg_cpu בטבלת התוצאות, הוא הגבוה ביותר במרווחי הזמן המודגשים שמסתיימים בשעה 17:00. בנוסף, שימו לב למספר גבוה בהרבה של שורות שנסרקו בממוצע. המשמעות היא ששאילתות יקרות יותר הופעלו בין השעות 16:50 ל-17:00. בוחרים את המרווח הזה כדי להמשיך לחקור אותו בשלב הבא.

איתור השאילתות שגורמות לשימוש גבוה ב-CPU

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

SELECT text_fingerprint AS fingerprint,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_cpu_seconds,3) AS cpu,
       ROUND(execution_count * avg_cpu_seconds,3) AS total_cpu
FROM spanner_sys.query_stats_top_10minute
WHERE
  interval_end = "2020-07-24T17:00:00Z"
ORDER BY total_cpu DESC;

הפעלת השאילתה הזו מניבה את התוצאות הבאות.

טביעת אצבע	ספירה	זמן טעינה	המעבד (CPU)	total_cpu
`5505124206529314852`	`30`	`3.88`	`17.635`	`529.039`
`1697951036096498470`	`10`	`4.49`	`18.388`	`183.882`
2295109096748351518	1	0.33	0.048	0.048
11618299167612903606	1	0.25	0.021	0.021
10302798842433860499	1	0.04	0.006	0.006
123771704548746223	1	0.04	0.006	0.006
4216063638051261350	1	0.04	0.006	0.006
3654744714919476398	1	0.04	0.006	0.006
2999453161628434990	1	0.04	0.006	0.006
823179738756093706	1	0.02	0.005	0.0056

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

השוואה בין הרצות של שאילתות לאורך זמן

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

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

SELECT interval_end,
       ROUND(avg_latency_seconds,2) AS latency,
       avg_rows AS rows_returned,
       avg_bytes AS bytes_returned,
       avg_rows_scanned AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS cpu,
FROM spanner_sys.query_stats_top_minute
WHERE text_fingerprint = 5505124206529314852
ORDER BY interval_end DESC;

הפעלת השאילתה הזו מחזירה את התוצאות הבאות.

interval_end	זמן טעינה	rows_returned	bytes_returned	rows_scanned	המעבד (CPU)
2020-07-24T17:00:00Z	4.55	21	2365	30000000	19.255
2020-07-24T16:00:00Z	3.62	21	2365	30000000	17.255
2020-07-24T15:00:00Z	4.37	21	2365	30000000	18.350
2020-07-24T14:00:00Z	4.02	21	2365	30000000	17.748
2020-07-24T13:00:00Z	‫3.12	21	2365	30000000	16.380
2020-07-24T12:00:00Z	3.45	21	2365	30000000	15.476
2020-07-24T11:00:00Z	4.94	21	2365	30000000	22.611
2020-07-24T10:00:00Z	6.48	21	2365	30000000	21.265
2020-07-24T09:00:00Z	0.23	21	2365	5	0.040
2020-07-24T08:00:00Z	0.04	21	2365	5	0.021
2020-07-24T07:00:00Z	0.09	21	2365	5	0.030

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

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

SELECT text,
       text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;

התוצאה שמתקבלת היא:

טקסט	text_truncated
select * from orders where o_custkey = 36901;	FALSE

כשבודקים את טקסט השאילתה שמוחזר, אפשר לראות שהשאילתה מסננת לפי שדה שנקרא o_custkey. זו עמודה ללא מפתח בטבלה orders. במקרה הזה, הייתה עמודה עם אינדקס שהוסר בסביבות השעה 9:00. זה מסביר את השינוי בעלות של השאילתה הזו. אפשר להוסיף את האינדקס בחזרה, או אם השאילתה מופעלת לעיתים רחוקות, אפשר להחליט לא להשתמש באינדקס ולקבל את עלות הקריאה הגבוהה יותר.

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

בדיקת שאילתות שנכשלו

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

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

SELECT interval_end,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS latency
FROM spanner_sys.query_stats_total_minute
WHERE
  interval_end >= "2020-07-24T16:50:00Z"
  AND interval_end <= "2020-07-24T17:00:00Z"
ORDER BY interval_end;

interval_end	failed_count	זמן טעינה
2020-07-24T16:52:00Z	1	15.211391
2020-07-24T16:53:00Z	3	58.312232

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

SELECT interval_end,
       text_fingerprint,
       execution_count,
       avg_latency_seconds AS avg_latency,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS failed_latency,
       cancelled_or_disconnected_execution_count AS cancel_count,
       timed_out_execution_count AS to_count
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;

interval_end	text_fingerprint	execution_count	failed_count	cancel_count	to_count
2020-07-24T16:52:00Z	5505124206529314852	3	1	1	0
2020-07-24T16:53:00Z	1697951036096498470	2	1	1	0
2020-07-24T16:53:00Z	5505124206529314852	5	2	1	1

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

SELECT interval_end,
       avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text_fingerprint = 5505124206529314852;

interval_end	combined_avg_latency	failed_execution_latency	success_execution_latency
2020-07-24T17:00:00Z	3.880420	13.830709	2.774832

יישום שיטות מומלצות

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

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

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

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

מתי כדאי להשתמש בנתוני סטטיסטיקה של שאילתות

איך ניגשים לסטטיסטיקות של שאילתות

שימוש במעבד (CPU) לפי שאילתה

סכמת טבלאות

נתונים סטטיסטיים מצטברים

סכמת טבלאות

שמירת נתונים

שאילתות לדוגמה

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

הצגת נתונים סטטיסטיים של פקודות DML עם חלוקה למחיצות שפועלות יותר משעה

תכין רשימה של השאילתות עם השימוש הכי גבוה ב-CPU

חיפוש המספר הכולל של ההפעלות בתקופה נתונה

מציאת זמן האחזור הממוצע של שאילתה

מציאת חביון האחוזון ה-99 של שאילתות

איתור השאילתות שסורקות הכי הרבה נתונים

איתור ההצהרות שכתבו הכי הרבה נתונים

סיכום השימוש במעבד בכל השאילתות

רשימת השאילתות שנכשלו בתקופת זמן נתונה

חיפוש המספר הכולל של השגיאות בתקופה מסוימת

רשימת השאילתות שפג הזמן הקצוב לתפוגה שלהן הכי הרבה פעמים

איך מוצאים את זמן האחזור הממוצע של ביצועים מוצלחים ושל ביצועים שנכשלו בשאילתה

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

בחירת תקופת זמן לבדיקה

איסוף נתונים סטטיסטיים של שאילתות לתקופת הזמן שנבחרה

איתור השאילתות שגורמות לשימוש גבוה ב-CPU

השוואה בין הרצות של שאילתות לאורך זמן

בדיקת שאילתות שנכשלו

יישום שיטות מומלצות

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

נתונים סטטיסטיים של שאילתות