MySQL 9.0 發行說明
效能架構是一種工具，可透過實際測量而非「「亂猜」」來協助 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;