羅小波·沃趣科技高階資料庫技術專家

   出品：沃趣科技

IT從業多年，歷任運維工程師、高階運維工程師、運維經理、資料庫工程師，曾參與版本釋出系統、輕量級監控系統、運維管理平臺、資料庫管理平臺的設計與編寫，熟悉MySQL體系結構，Innodb儲存引擎，喜好專研開源技術，追求完美。

導語

在上一篇 《配置詳解 | performance_schema全方位介紹》 中，我們詳細介紹了performance_schema的配置表，堅持讀完的是真愛，也恭喜大家翻過了一座火焰山。相信有不少人讀完之後，已經迫不及待的想要躍躍欲試了，今天將帶領大家一起踏上系列第三篇的征程(全系共6個篇章)，在這一期裡，我們將為大家全面講解performance_schema中事件原始記錄表。下面，請跟隨我們一起開始performance_schema系統的學習之旅吧。

等待事件表

通常，我們在碰到效能瓶頸時，如果其他的方法難以找出效能瓶頸的時候(例如：硬體負載不高、SQL優化和庫表結構優化都難以奏效的時候)，我們常常需要藉助於等待事件來進行分析，找出在MySQL Server內部，到底資料庫響應慢是慢在哪裡。

等待事件記錄表包含三張表，這些表記錄了當前與最近在MySQL例項中發生了哪些等待事件，時間消耗是多少。

• events_waits_current表：記錄當前正在執行的等待事件的，每個執行緒只記錄1行記錄

• events_waits_history表：記錄已經執行完的最近的等待事件歷史，預設每個執行緒只記錄10行記錄

• events_waits_history_long表：記錄已經執行完的最近的等待事件歷史，預設所有執行緒的總記錄行數為10000行

要注意：等待事件相關配置中，setup_instruments表中絕大部分的等待事件instruments都沒有開啟(IO相關的等待事件instruments預設大部分已開啟)，setup_consumers表中waits相關的consumers配置預設沒有開啟

events_waits_current 表

events_waits_current表包含當前的等待事件資訊，每個執行緒只顯示一行最近監視的等待事件的當前狀態

在所有包含等待事件行的表中，events_waits_current表是最基礎的資料來源。其他包含等待事件資料表在邏輯上是來源於events_waits_current表中的當前事件資訊（彙總表除外）。例如，events_waits_history和events_waits_history_long表中的資料是events_waits_current表資料的一個小集合彙總（具體存放多少行資料集合有各自的變數控制）

表記錄內容示例（這是一個執行select sleep(100);語句的執行緒等待事件資訊）

[email protected] : performance_schema 12:15:03> select * from events_waits_current where EVENT_NAME='wait/synch/cond/sql/Item_func_sleep::cond'\G;
*************************** 1. row ***************************
        THREAD_ID: 46
        EVENT_ID: 140
    END_EVENT_ID: NULL
      EVENT_NAME: wait/synch/cond/sql/Item_func_sleep::cond
          SOURCE: item_func.cc:5261
      TIMER_START: 14128809267002592
        TIMER_END: 14132636159944419
      TIMER_WAIT: 3826892941827
            SPINS: NULL
    OBJECT_SCHEMA: NULL
      OBJECT_NAME: NULL
      INDEX_NAME: NULL
      OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 140568905519072
NESTING_EVENT_ID: 116
NESTING_EVENT_TYPE: STATEMENT
        OPERATION: timed_wait
  NUMBER_OF_BYTES: NULL
            FLAGS: NULL
1 row in set (0.00 sec)

上面的輸出結果中，TIMER_WAIT欄位即表示該事件的時間開銷，單位是皮秒，在實際的應用場景中，我們可以利用該欄位資訊進行倒序排序，以便找出時間開銷最大的等待事件。

events_waits_current表完整的欄位含義如下：

THREAD_ID，EVENT_ID：與事件關聯的執行緒ID和當前事件ID。THREAD_ID和EVENT_ID值構成了該事件資訊行的唯一標識（不會有重複的THREAD_ID+EVENT_ID值）

END_EVENT_ID：當一個事件正在執行時該列值為NULL，當一個事件執行結束時把該事件的ID更新到該列

EVENT_NAME：產生事件的instruments名稱。該名稱來自setup_instruments表的NAME欄位值

SOURCE：產生該事件的instruments所在的原始檔名稱以及檢測到該事件發生點的程式碼行號。您可以檢視原始碼來確定涉及的程式碼。例如，如果互斥鎖、鎖被阻塞，您可以檢查發生這種情況的上下文環境

TIMER_START，TIMER_END，TIMER_WAIT：事件的時間資訊。單位皮秒（萬億分之一秒）。 TIMER_START和TIMER_END值表示事件開始和結束時間。 TIMER_WAIT是事件經過時間（即事件執行了多長時間） 

• 如果事件未執行完成，則TIMER_END為當前計時器時間值（當前時間），TIMER_WAIT為目前為止所經過的時間（TIMER_END - TIMER_START） 

• 如果採集該事件的instruments配置項TIMED = NO，則不會收集事件的時間資訊，TIMER_START，TIMER_END和TIMER_WAIT在這種情況下均記錄為NULL 

SPINS：對於互斥量和自旋次數。如果該列值為NULL，則表示程式碼中沒有使用自旋或者說自旋沒有被監控起來 

OBJECT_SCHEMA，OBJECT_NAME，OBJECT_TYPE，OBJECT_INSTANCE_BEGIN：這些列標識了一個正在被執行的物件，所以這些列記錄的資訊含義需要看物件是什麼型別，下面按照不同物件型別分別對這些列的含義進行說明： 

* 對於同步物件（cond，mutex，rwlock）： 

* 1)、OBJECT_SCHEMA，OBJECT_NAME和OBJECT_TYPE列值都為NULL

* 2)、OBJECT_INSTANCE_BEGIN列是記憶體中同步物件的地址。OBJECT_INSTANCE_BEGIN除了不同的值標記不同的物件之外，其值本身沒有意義。但OBJECT_INSTANCE_BEGIN值可用於除錯。例如，它可以與GROUP BY OBJECT_INSTANCE_BEGIN子句一起使用來檢視1,000個互斥體（例如：保護1,000個頁或資料塊）上的負載是否是均勻分佈還是發生了一些瓶頸。如果在日誌檔案或其他除錯、效能工具中看到與該語句檢視的結果中有相同的物件地址，那麼，在你分析效能問題時，可以把這個語句檢視到的資訊與其他工具檢視到的資訊關聯起來。 

* 對於檔案I/O物件： 

* 1)、OBJECT_SCHEMA列值為NULL 
* 2)、OBJECT_NAME列是檔名 
* 3)、OBJECT_TYPE列為FILE 
* 4)、OBJECT_INSTANCE_BEGIN列是記憶體中的地址，解釋同上 

* 對於套接字物件：

* 1)、OBJECT_NAME列是套接字的IP：PORT值 

* 2)、OBJECT_INSTANCE_BEGIN列是記憶體中的地址，解釋同上 

* 對於表I/O物件： 

* 1)、OBJECT_SCHEMA列是包含該表的庫名稱 

* 2)、OBJECT_NAME列是表名 

* 3)、OBJECT_TYPE列值對於基表或者TEMPORARY TABLE臨時表，該值是table，注意：對於在join查詢中select_type為DERIVED，subquery等的表可能不記錄事件資訊也不進行統計 

* 4)、OBJECT_INSTANCE_BEGIN列是記憶體中的地址，解釋同上

INDEX_NAME：表示使用的索引的名稱。PRIMARY表示使用到了主鍵。 NULL表示沒有使用索引

NESTING_EVENT_ID：表示該行資訊中的EVENT_ID事件是巢狀在哪個事件中，即父事件的EVENT_ID

NESTING_EVENT_TYPE：表示該行資訊中的EVENT_ID事件巢狀的事件型別。有效值有：TRANSACTION，STATEMENT，STAGE或WAIT，即父事件的事件型別，如果為TRANSACTION則需要到事務事件表中找對應NESTING_EVENT_ID值的事件，其他型別同理

OPERATION：執行的操作型別，如：lock、read、write、timed_wait

NUMBER_OF_BYTES：操作讀取或寫入的位元組數或行數。對於檔案IO等待，該列值表示位元組數；對於表I/O等待（wait/io/table/sql/handler instruments的事件），該列值表示行數。如果值大於1，則表示該事件對應一個批量I/O操作。以下分別對單個表IO和批量表IO的區別進行描述： 

• MySQL的join查詢使用巢狀迴圈實現。performance_schema instruments的作用是在join查詢中提供對每個表的掃描行數和執行時間進行統計。示例：join查詢語句：SELECT … FROM t1 JOIN t2 ON … JOIN t3 ON …，假設join順序是t1，t2，t3 

• 在join查詢中，一個表在查詢時與其他表展開聯結查詢之後，該表的掃描行數可能增加也可能減少，例如：如果t3表扇出大於1，則大多數row fetch操作都是針對t3表，假如join查詢從t1表訪問10行記錄，然後使用t1表驅動查詢t2表，t1表的每一行都會掃描t2表的20行記錄，然後使用t2表驅動查詢t3表，t2表的每一行都會掃描t3表的30行記錄，那麼，在使用單行輸出時，instruments統計操作的事件資訊總行數為：10 +（10 * 20）+（10 * 20 * 30）= 6210 

• 通過對錶中行掃描時的instruments統計操作進行聚合（即，每個t1和t2的掃描行數在instruments統計中可以算作一個批量組合），這樣就可以減少instruments統計操作的數量。通過批量I/O輸出方式，performance_schema每次對最內層表t3的掃描減少為一個事件統計資訊而不是每一行掃描都生成一個事件資訊，此時對於instruments統計操作的事件行數量減少到：10 +（10 * 20）+（10 * 20）= 410，這樣在該join查詢中對於performance_schema中的行統計操作就減少了93％，批量輸出策略通過減少輸出行數量來顯著降低表I/O的performance_schema統計開銷。但是相對於每行資料都單獨執行統計操作，會損失對時間統計的準確度。在join查詢中，批量I/O統計的時間包括用於連線緩衝、聚合和返回行到客戶端的操作所花費的時間（即就是整個join語句的執行時間）

FLAGS：留作將來使用

PS：events_waits_current表允許使用TRUNCATE TABLE語句

events_waits_history 表

events_waits_history表包含每個執行緒最近的N個等待事件。 在server啟動時，N的值會自動調整。 如果要顯式設定這個N大小，可以在server啟動之前調整系統引數performance_schema_events_waits_history_size的值。 等待事件需要執行結束時才被新增到events_waits_history表中（沒有結束時儲存在events_waits_current表）。當新增新事件到events_waits_history表時，如果該表已滿，則會丟棄每個執行緒較舊的事件

events_waits_history與events_waits_current表定義相同

PS：允許執行TRUNCATE TABLE語句

events_waits_history_long 表

events_waits_history_long表包含最近的N個等待事件（所有執行緒的事件）。在server啟動時，N的值會自動調整。 如果要顯式設定這個N大小，可以在server啟動之前調整系統引數

performance_schema_events_waits_history_long_size的值。等待事件需要執行結束時才會被新增到events_waits_history_long表中（沒有結束時儲存在events_waits_current表），當新增新事件到events_waits_history_long表時，如果該表已滿，則會丟棄該表中較舊的事件。

events_waits_history_long與events_waits_current表結構相同

PS：允許使用TRUNCATE TABLE語句

階段事件表

階段事件記錄表與等待事件記錄表一樣，也有三張表，這些表記錄了當前與最近在MySQL例項中發生了哪些階段事件，時間消耗是多少。階段指的是語句執行過程中的步驟，例如：parsing 、opening tables、filesort操作等。

在以往我們檢視語句執行的階段狀態，常常使用SHOW PROCESSLIST語句或查詢INFORMATION_SCHEMA.PROCESSLIST表來獲得，但processlist方式能夠查詢到的資訊比較有限且轉瞬即逝，我們常常需要結合profiling功能來進一步統計分析語句執行的各個階段的開銷等，現在，我們不需要這麼麻煩，直接使用performance_schema的階段事件就既可以查詢到所有的語句執行階段，也可以查詢到各個階段對應的開銷，因為是記錄在表中，所以更可以使用SQL語句對這些資料進行排序、統計等操作

要注意：階段事件相關配置中，setup_instruments表中stage/開頭的絕大多數instruments配置預設沒有開啟（少數stage/開頭的instruments除外，如DDL語句執行過程的stage/innodb/alter*開頭的instruments預設開啟的），setup_consumers表中stages相關的consumers配置預設沒有開啟

events_stages_current 表

events_stages_current表包含當前階段事件的監控資訊，每個執行緒一行記錄顯示執行緒正在執行的stage事件的狀態

在包含stage事件記錄的表中，events_stages_current是基準表，包含stage事件記錄的其他表（如：events_stages_history和events_stages_history_long表）的資料在邏輯上都來自events_stages_current表（彙總表除外） 

表記錄內容示例(以下仍然是一個執行select sleep(100);語句的執行緒，但這裡是階段事件資訊)

[email protected] : performance_schema 12:24:40> select * from events_stages_current where EVENT_NAME='stage/sql/User sleep'\G;
*************************** 1. row ***************************
    THREAD_ID: 46
      EVENT_ID: 280
  END_EVENT_ID: NULL
    EVENT_NAME: stage/sql/User sleep
        SOURCE: item_func.cc:6056
  TIMER_START: 14645080545642000
    TIMER_END: 14698320697396000
    TIMER_WAIT: 53240151754000
WORK_COMPLETED: NULL
WORK_ESTIMATED: NULL
NESTING_EVENT_ID: 266
NESTING_EVENT_TYPE: STATEMENT
1 row in set (0.00 sec)

以上的輸出結果與語句的等待事件形式類似，這裡不再贅述，events_stages_current表完整的欄位含義如下：

THREAD_ID，EVENT_ID：與事件關聯的執行緒ID和當前事件ID，可以使用THREAD_ID和EVENT_ID列值來唯一標識該行，這兩行的值作為組合條件時不會出現相同的資料行

END_EVENT_ID：當一個事件開始執行時，對應行記錄的該列值被設定為NULL，當一個事件執行結束時，對應的行記錄的該列值被更新為該事件的ID

EVENT_NAME：產生事件的instruments的名稱。該列值來自setup_instruments表的NAME值。instruments名稱可能具有多個部分並形成層次結構，如："stage/sql/Slave has read all relay log; waiting for more updates"，其中stage是頂級名稱，sql是二級名稱，Slave has read all relay log; waiting for more updates是第三級名稱。詳見連結：

https://dev.mysql.com/doc/refman/5.7/en/performance-schema-instrument-naming.html

SOURCE：原始檔的名稱及其用於檢測該事件的程式碼位於原始檔中的行號

TIMER_START，TIMER_END，TIMER_WAIT：事件的時間資訊。這些值的單位是皮秒（萬億分之一秒）。 TIMER_START和TIMER_END值表示事件的開始時間和結束時間。TIMER_WAIT是事件執行消耗的時間（持續時間） 

• 如果事件未執行完成，則TIMER_END為當前時間，TIMER_WAIT為當前為止所經過的時間（TIMER_END - TIMER_START）

• 如果instruments配置表setup_instruments中對應的instruments 的TIMED欄位被設定為 NO，則該instruments禁用時間收集功能，那麼事件採集的資訊記錄中，TIMER_START，TIMER_END和TIMER_WAIT欄位值均為NULL

WORK_COMPLETED，WORK_ESTIMATED：這些列提供了階段事件進度資訊 

• 表中的WORK_COMPLETED和WORK_ESTIMATED兩列，它們共同協作顯示每一行的進度顯示： 

* 1)、WORK_COMPLETED：顯示階段事件已完成的工作單元數 

* 2)、WORK_ESTIMATED：顯示預計階段事件將要完成的工作單元數 

• 如果instruments沒有提供進度相關的功能，則該instruments執行事件採集時就不會有進度資訊顯示，WORK_COMPLETED和WORK_ESTIMATED列都會顯示為NULL。如果進度資訊可用，則進度資訊如何顯示取決於instruments的執行情況。performance_schema表提供了一個儲存進度資料的容器，但不會假設你會定義何種度量單位來使用這些進度資料： 

* 1)、“工作單元”是在執行過程中隨時間增加而增加的整數度量，例如執行過程中的位元組數、行數、檔案數或表數。對於特定instruments的“工作單元”的定義留給提供資料的instruments程式碼 

* 2)、WORK_COMPLETED值根據檢測的程式碼不同，可以一次增加一個或多個單元 

* 3)、WORK_ESTIMATED值根據檢測程式碼，可能在階段事件執行過程中發生變化 

• 階段事件進度指示器的表現行為有以下幾種情況： 

* 1)、instruments不支援進度：沒有可用進度資料， WORK_COMPLETED和WORK_ESTIMATED列都顯示為NULL 

* 2) 、instruments支援進度但對應的工作負載總工作量不可預估（無限進度）：只有WORK_COMPLETED列有意義（因為他顯示正在執行的進度顯示），WORK_ESTIMATED列此時無效，顯示為0，因為沒有可預估的總進度資料。通過查詢events_stages_current表來監視會話，監控應用程式到目前為止執行了多少工作，但無法報告對應的工作是否接近完成 

* 3)、instruments支援進度，總工作量可預估（有限進度）：WORK_COMPLETED和WORK_ESTIMATED列值有效。這種型別的進度顯示可用於online DDL期間的copy表階段監視。通過查詢events_stages_current表，可監控應用程式當前已經完成了多少工作，並且可以通過WORK_COMPLETED / WORK_ESTIMATED計算的比率來預估某個階段總體完成百分比

NESTING_EVENT_ID：事件的巢狀事件EVENT_ID值（父事件ID）

NESTING_EVENT_TYPE：巢狀事件型別。有效值為：TRANSACTION，STATEMENT，STAGE，WAIT。階段事件的巢狀事件通常是statement

對於events_stages_current表允許使用TRUNCATE TABLE語句來進行清理

PS：stage事件擁有一個進度展示功能，我們可以利用該進度展示功能來了解一些長時間執行的SQL的進度百分比，例如：對於需要使用COPY方式執行的online ddl，那麼需要copy的資料量是一定的，可以明確的，so..這就可以為"stage/sql/copy to tmp table stage" instruments提供一個有結束邊界參照的進度資料資訊，這個instruments所使用的工作單元就是需要複製的資料行數，此時WORK_COMPLETED和WORK_ESTIMATED列值都是有效的可用的，兩者的計算比例就表示當前copy表完成copy的行資料百分比。

• 要檢視copy表階段事件的正在執行的進度監視功能，需要開啟相關的instruments和consumers，然後檢視events_stages_current表，如下：

# 配置相關instruments和consumers
UPDATE setup_instruments SET ENABLED='YES' WHERE NAME='stage/sql/copy to tmp table';
UPDATE setup_consumers SET ENABLED='YES' WHERE NAME LIKE 'events_stages_%';
# 然後在執行ALTER TABLE語句期間，檢視events_stages_current表

events_stages_history 表

events_stages_history表包含每個執行緒最新的N個階段事件。 在server啟動時，N的值會自動調整。 如果要顯式設定N值大小，可以在server啟動之前設定系統變數performance_schema_events_stages_history_size的值。stages事件在執行結束時才新增到events_stages_history表中。 當新增新事件到events_stages_history表時，如果events_stages_history表已滿，則會丟棄對應執行緒較舊的事件events_stages_history與events_stages_current表結構相同

PS：允許使用TRUNCATE TABLE語句

events_stages_history_long 表

events_stages_history_long表包含最近的N個階段事件。 在server啟動時，N的值會自動調整。 如果要顯式設定N值大小，可以在server啟動之前設定系統變數performance_schema_events_stages_history_long_size的值。stages事件執行結束時才會新增到events_stages_history_long表中，當新增新事件到events_stages_history_long表時，如果events_stages_history_long表已滿，則會丟棄該表中較舊的事件events_stages_history_long與events_stages_current表結構相同 

PS：允許使用TRUNCATE TABLE語句

語句事件表

語句事件記錄表與等待事件記錄表一樣，也有三張表，這些表記錄了當前與最近在MySQL例項中發生了哪些語句事件，時間消耗是多少。記錄了各種各樣的語句執行產生的語句事件資訊。 

要注意：語句事件相關配置中，setup_instruments表中statement/*開頭的所有instruments配置預設開啟，setup_consumers表中statements相關的consumers配置預設開啟了events_statements_current、events_statements_history、statements_digest（對應events_statements_summary_by_digest表，詳見後續章節）但沒有開啟events_statements_history_long。

events_statements_current 表

events_statements_current表包含當前語句事件，每個執行緒只顯示一行最近被監視語句事件的當前狀態。

在包含語句事件行的表中，events_statements_current當前事件表是基礎表。其他包含語句事件表中的資料在邏輯上來源於當前事件表（彙總表除外）。例如：events_statements_history和events_statements_history_long表是最近的語句事件歷史的集合，events_statements_history表中每個執行緒預設保留10行事件歷史資訊，events_statements_history_long表中預設所有執行緒保留10000行事件歷史資訊

表記錄內容示例（以下資訊仍然來自select sleep(100);語句的語句事件資訊）

[email protected] : performance_schema 12:36:35> select * from events_statements_current where SQL_TEXT='select sleep(100)'\G;
*************************** 1. row ***************************
          THREAD_ID: 46
          EVENT_ID: 334
      END_EVENT_ID: NULL
        EVENT_NAME: statement/sql/select
            SOURCE: socket_connection.cc:101
        TIMER_START: 15354770719802000
          TIMER_END: 15396587017809000
        TIMER_WAIT: 41816298007000
          LOCK_TIME: 0
          SQL_TEXT: select sleep(100)
            DIGEST: NULL
        DIGEST_TEXT: NULL
    CURRENT_SCHEMA: NULL
        OBJECT_TYPE: NULL
      OBJECT_SCHEMA: NULL
        OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
        MYSQL_ERRNO: 0
  RETURNED_SQLSTATE: NULL
      MESSAGE_TEXT: NULL
            ERRORS: 0
          WARNINGS: 0
      ROWS_AFFECTED: 0
          ROWS_SENT: 0
      ROWS_EXAMINED: 0
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
  SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
      SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
        SELECT_SCAN: 0
  SORT_MERGE_PASSES: 0
        SORT_RANGE: 0
          SORT_ROWS: 0
          SORT_SCAN: 0
      NO_INDEX_USED: 0
NO_GOOD_INDEX_USED: 0
  NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
NESTING_EVENT_LEVEL: 0
1 row in set (0.00 sec)

以上的輸出結果與語句的等待事件形式類似，這裡不再贅述，events_statements_current表完整的欄位含義如下：

THREAD_ID，EVENT_ID：與事件關聯的執行緒號和事件啟動時的事件編號，可以使用THREAD_ID和EVENT_ID列值來唯一標識該行，這兩行的值作為組合條件時不會出現相同的資料行

END_EVENT_ID：當一個事件開始執行時，對應行記錄的該列值被設定為NULL，當一個事件執行結束時，對應的行記錄的該列值被更新為該事件的ID

EVENT_NAME：產生事件的監視儀器的名稱。該列值來自setup_instruments表的NAME值。對於SQL語句，EVENT_NAME值最初的instruments是statement/com/Query，直到語句被解析之後，會更改為更合適的具體instruments名稱，如：statement/sql/insert

SOURCE：原始檔的名稱及其用於檢測該事件的程式碼位於原始檔中的行號，您可以檢查原始碼來確定涉及的程式碼

TIMER_START，TIMER_END，TIMER_WAIT：事件的時間資訊。這些值的單位是皮秒（萬億分之一秒）。 TIMER_START和TIMER_END值表示事件的開始時間和結束時間。TIMER_WAIT是事件執行消耗的時間（持續時間） 

• 如果事件未執行完成，則TIMER_END為當前時間，TIMER_WAIT為當前為止所經過的時間（TIMER_END - TIMER_START）。 

• 如果監視儀器配置表setup_instruments中對應的監視器TIMED欄位被設定為 NO，則不會收集該監視器的時間資訊，那麼對於該事件採集的資訊記錄中，TIMER_START，TIMER_END和TIMER_WAIT欄位值均為NULL 

LOCK_TIME：等待表鎖的時間。該值以微秒進行計算，但最終轉換為皮秒顯示，以便更容易與其他performance_schema中的計時器進行比較

SQL_TEXT：SQL語句的文字。如果該行事件是與SQL語句無關的command事件，則該列值為NULL。預設情況下，語句最大顯示長度為1024位元組。如果要修改，則在server啟動之前設定系統變數performance_schema_max_sql_text_length的值 

DIGEST：語句摘要的MD5 hash值，為32位十六進位制字串，如果在setup_consumers表中statement_digest配置行沒有開啟，則語句事件中該列值為NULL 

DIGEST_TEXT：標準化轉換過的語句摘要文字，如果setup_consumers表中statements_digest配置行沒有開啟，則語句事件中該列值為NULL。performance_schema_max_digest_length系統變數決定著在存入該表時的最大摘要語句文字的位元組長度（預設為1024位元組），要注意：用於計算摘要語句文字的原始語句文字位元組長度由系統變數max_digest_length控制，而存入表中的位元組長度由系統變數performance_schema_max_digest_length控制，所以，如果performance_schema_max_digest_length小於max_digest_length時，計算出的摘要語句文字如果大於了performance_schema_max_digest_length定義的長度會被截斷

CURRENT_SCHEMA：語句使用的預設資料庫（使用use db_name語句即可指定預設資料庫），如果沒有則為NULL 

OBJECT_SCHEMA，OBJECT_NAME，OBJECT_TYPE：對於巢