MySQL 8.4 版本注意事項
效能架構是一個工具，可透過實際測量而非「亂猜」來幫助 DBA 進行效能調整。本節示範一些使用效能架構達到此目的的方法。此處的討論依賴於事件篩選的使用，這在第 29.4.2 節「效能架構事件篩選」中說明。
以下範例提供一種方法，可用於分析可重複的問題，例如調查效能瓶頸。首先，您應該有一個可重複的使用案例，其中效能被認為「太慢」而需要最佳化，並且您應該啟用所有檢測（完全不進行預先篩選）。
執行使用案例。
使用效能架構表格，分析效能問題的根本原因。此分析主要依賴於後篩選。
對於排除的問題區域，停用相應的工具。例如，如果分析顯示問題與特定儲存引擎中的檔案 I/O 無關，則停用該引擎的檔案 I/O 工具。然後截斷歷史記錄和摘要表格，以移除先前收集的事件。
在步驟 1 中重複此流程。
每次迭代時，效能架構輸出，特別是
events_waits_history_long表格，包含的「雜訊」越來越少（由非顯著的工具引起），並且由於此表格的大小固定，因此包含越來越多與手頭問題分析相關的資料。隨著每次迭代，調查應該越來越接近問題的根本原因，因為「訊號/雜訊」比率會提高，使分析更加容易。
一旦確定效能瓶頸的根本原因，請採取適當的更正措施，例如
調整伺服器參數（快取大小、記憶體等等）。
透過不同的撰寫方式調整查詢，
調整資料庫結構描述（表格、索引等等）。
調整程式碼（這僅適用於儲存引擎或伺服器開發人員）。
從步驟 1 重新開始，查看變更對效能的影響。
mutex_instances.LOCKED_BY_THREAD_ID 和 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 欄位對於調查效能瓶頸或死鎖至關重要。這可透過 Performance Schema 的儀器化功能實現，如下所示：
假設執行緒 1 正在等待一個互斥鎖而被卡住。
您可以判斷該執行緒正在等待什麼。
SELECT * FROM performance_schema.events_waits_current WHERE THREAD_ID = thread_1;假設查詢結果識別出該執行緒正在等待互斥鎖 A，該互斥鎖可以在
events_waits_current.OBJECT_INSTANCE_BEGIN中找到。您可以判斷哪個執行緒持有互斥鎖 A。
SELECT * FROM performance_schema.mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;假設查詢結果識別出是執行緒 2 持有互斥鎖 A，此資訊可以在
mutex_instances.LOCKED_BY_THREAD_ID中找到。您可以查看執行緒 2 正在做什麼。
SELECT * FROM performance_schema.events_waits_current WHERE THREAD_ID = thread_2;