MySQL 8.4 版本資訊
mutex_instances 資料表列出伺服器執行時 Performance Schema 所見的所有互斥鎖。互斥鎖是程式碼中使用的同步機制，用以強制在給定時間內只有一個執行緒可以存取某些共用資源。該資源被稱為由互斥鎖「保護」。
當伺服器中執行的兩個執行緒（例如，兩個使用者工作階段同時執行查詢）確實需要存取相同的資源（檔案、緩衝區或某些資料片段）時，這兩個執行緒會相互競爭，因此第一個取得互斥鎖鎖定的查詢會導致另一個查詢等待，直到第一個查詢完成並解除互斥鎖。
在持有互斥鎖時執行的工作被稱為處於「臨界區段」，多個查詢會以序列方式（一次一個）執行此臨界區段，這是一個潛在的瓶頸。
mutex_instances 資料表具有下列欄位
NAME與互斥鎖相關聯的儀器名稱。
OBJECT_INSTANCE_BEGIN已檢測互斥鎖在記憶體中的位址。
LOCKED_BY_THREAD_ID當執行緒目前鎖定互斥鎖時，
LOCKED_BY_THREAD_ID是鎖定執行緒的THREAD_ID，否則為NULL。
mutex_instances 資料表具有下列索引
以 (
OBJECT_INSTANCE_BEGIN) 作為主要索引鍵以 (
NAME) 作為索引以 (
LOCKED_BY_THREAD_ID) 作為索引
不允許對 mutex_instances 資料表使用 TRUNCATE TABLE。
對於程式碼中檢測的每個互斥鎖，Performance Schema 都會提供下列資訊。
setup_instruments資料表列出檢測點的名稱，帶有字首wait/synch/mutex/。當某些程式碼建立互斥鎖時，會將一個資料列新增至
mutex_instances表格。OBJECT_INSTANCE_BEGIN欄位是唯一識別該互斥鎖的屬性。當執行緒嘗試鎖定互斥鎖時，
events_waits_current表格會顯示該執行緒的資料列，表示它正在等待互斥鎖（在EVENT_NAME欄位中），並指出正在等待哪個互斥鎖（在OBJECT_INSTANCE_BEGIN欄位中）。當執行緒成功鎖定互斥鎖時
events_waits_current會顯示在互斥鎖上的等待已完成（在TIMER_END和TIMER_WAIT欄位中）已完成的等待事件會新增至
events_waits_history和events_waits_history_long表格mutex_instances顯示該互斥鎖現在由該執行緒擁有（在THREAD_ID欄位中）。
當執行緒解除鎖定互斥鎖時，
mutex_instances顯示該互斥鎖現在沒有擁有者（THREAD_ID欄位為NULL）。當互斥鎖物件被銷毀時，對應的資料列會從
mutex_instances中移除。
透過對以下兩個表格執行查詢，監控應用程式或 DBA 可以偵測到涉及互斥鎖的執行緒之間的瓶頸或死結
events_waits_current，以查看執行緒正在等待哪個互斥鎖mutex_instances，以查看目前哪個其他執行緒擁有互斥鎖