MySQL 8.4 發行說明
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_instruments表格的NAME值。工具名稱可能包含多個部分並形成階層結構，如第 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是記憶體中的位址。
對於 Socket 物件
OBJECT_NAME是 Socket 的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每從t1取一列存取 20 列，從t3每從資料表t2取一列存取 30 列。使用單列報告，工具化的操作總數為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_current 資料表使用 TRUNCATE TABLE。它會移除列。