MySQL 9.0 發行說明
events_waits_current 資料表包含目前的等待事件。此資料表針對每個執行緒儲存一列，顯示執行緒最近一次監控的等待事件的目前狀態，因此沒有用於設定資料表大小的系統變數。
在包含等待事件列的資料表中，events_waits_current 是最基本的。其他包含等待事件列的資料表都是從目前的事件邏輯衍生而來。例如，events_waits_history 和 events_waits_history_long 資料表分別是已結束的最近等待事件的集合，每個執行緒和全域所有執行緒都有最大列數限制。
如需有關三個等待事件資料表之間關係的更多資訊，請參閱章節 29.9，「Performance Schema 目前和歷史事件資料表」。
如需有關設定是否收集等待事件的資訊，請參閱章節 29.12.4，「Performance Schema 等待事件資料表」。
events_waits_current
THREAD_ID、EVENT_ID與事件關聯的執行緒，以及事件開始時該執行緒的目前事件編號。
THREAD_ID和EVENT_ID值組合在一起可唯一識別該列。沒有任何兩列具有相同的值對。END_EVENT_ID此欄位在事件開始時設定為
NULL，並在事件結束時更新為執行緒的目前事件編號。EVENT_NAME產生事件的儀器名稱。這是來自
setup_instrumentsNAME值。儀器名稱可能包含多個部分，並形成一個階層，如 第 29.6 節，〈效能綱要儀器命名慣例〉 中所述。SOURCE包含產生事件的檢測程式碼的來源檔案名稱，以及檔案中發生檢測的行號。這可讓您檢查來源以確定確切涉及的程式碼。例如，如果某個互斥鎖或鎖定被封鎖，您可以檢查此情況發生的上下文。
TIMER_START、TIMER_END、TIMER_WAIT事件的計時資訊。這些值的單位是皮秒（一秒的兆分之一）。
TIMER_START和TIMER_END值表示事件計時開始和結束的時間。TIMER_WAIT是事件經過的時間（持續時間）。如果事件尚未完成，則
TIMER_END是目前的計時器值，而TIMER_WAIT是目前為止經過的時間（TIMER_END−TIMER_START）。如果事件是由具有
TIMED = NO的儀器產生，則不會收集計時資訊，而且TIMER_START、TIMER_END和TIMER_WAIT全都是NULL。如需關於將皮秒作為事件時間單位以及影響時間值的因素的討論，請參閱第 29.4.1 節，〈效能綱要事件計時〉。
SPINS對於互斥鎖，這是旋轉輪次的數量。如果該值為
NULL，則程式碼不會使用旋轉輪次，或未檢測旋轉。OBJECT_SCHEMA、OBJECT_NAME、OBJECT_TYPE、OBJECT_INSTANCE_BEGIN這些欄位識別 「正在被作用的」物件。其意義取決於物件類型。
對於同步物件（
cond、mutex、rwlock）OBJECT_SCHEMA、OBJECT_NAME和OBJECT_TYPE是NULL。OBJECT_INSTANCE_BEGIN是記憶體中同步物件的位址。
對於檔案 I/O 物件
OBJECT_SCHEMA是NULL。OBJECT_NAME是檔案名稱。OBJECT_TYPE是FILE。OBJECT_INSTANCE_BEGIN是記憶體中的位址。
對於通訊端物件
OBJECT_NAME是通訊端的IP:PORT值。OBJECT_INSTANCE_BEGIN是記憶體中的位址。
對於資料表 I/O 物件
OBJECT_SCHEMA是包含資料表的綱要名稱。OBJECT_NAME是資料表名稱。OBJECT_TYPE對於永久基底資料表是TABLE，對於暫時資料表是TEMPORARY TABLE。OBJECT_INSTANCE_BEGIN是記憶體中的位址。
OBJECT_INSTANCE_BEGIN值本身沒有任何意義，除非不同的值表示不同的物件。OBJECT_INSTANCE_BEGIN可用於偵錯。例如，它可以與GROUP BY OBJECT_INSTANCE_BEGIN搭配使用，以查看 1,000 個互斥鎖（例如，保護 1,000 個資料頁面或區塊）的負載是否平均分散，還是只集中在少數幾個瓶頸。如果您在記錄檔或其他偵錯或效能工具中看到相同的物件位址，這可以幫助您與其他資訊來源建立關聯。INDEX_NAME所使用索引的名稱。
PRIMARY表示資料表主索引。NULL表示未使用任何索引。NESTING_EVENT_ID此事件所巢狀於其中的事件的
EVENT_ID值。NESTING_EVENT_TYPE巢狀事件類型。值為
TRANSACTION、STATEMENT、STAGE或WAIT。OPERATION執行的操作類型，例如
lock、read或write。NUMBER_OF_BYTES操作讀取或寫入的位元組數。對於資料表 I/O 等候（
wait/io/table/sql/handler儀器的事件），NUMBER_OF_BYTES表示資料列數。如果該值大於 1，則事件為批次 I/O 操作。以下討論描述了獨有的單列報告與反映批次 I/O 的報告之間的差異。MySQL 使用巢狀迴圈實作來執行聯結。效能綱要儀器的任務是提供聯結中每個資料表的資料列計數和累積執行時間。假設聯結查詢採用以下形式，並使用
t1、t2、t3的資料表聯結順序來執行SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...資料表「扇出」是在聯結處理期間，新增資料表時資料列數的增加或減少。如果資料表
t3的扇出大於 1，則大多數資料列提取操作都是針對該資料表。假設聯結從t1存取 10 列，從t2存取每一列t120 列，以及從t3存取每一列資料表t230 列。使用單列報告，檢測操作的總數為10 + (10 * 20) + (10 * 20 * 30) = 6210如果按掃描彙總檢測的操作（也就是按
t1和t2資料列的唯一組合），則檢測操作的數量可以大幅減少。使用批次 I/O 報告，效能綱要會為最內層資料表t3的每次掃描產生一個事件，而不是為每個資料列產生一個事件，而檢測的資料列操作次數會減少為10 + (10 * 20) + (10 * 20) = 410減少了 93%，這說明了批次報告策略如何透過減少報告呼叫次數，大幅降低效能綱要針對資料表 I/O 的額外負荷。其缺點是事件計時的精確度降低。相較於每個資料列報告中個別資料列操作的時間，批次 I/O 的計時包含用於聯結緩衝、彙總以及將資料列返回給用戶端等操作所花費的時間。
若要發生批次 I/O 報告，必須符合以下條件
查詢執行會存取查詢區塊的最內層資料表（對於單資料表查詢，該資料表會計為最內層資料表）
查詢執行不會從資料表請求單一資料列（因此，例如，
eq_ref存取會防止使用批次報告）查詢執行不會評估包含資料表存取之資料表的子查詢
FLAGS保留供未來使用。
events_waits_current
在 (
THREAD_ID,EVENT_ID) 上的主鍵
允許針對 events_waits_currentTRUNCATE TABLE