MySQL 5.5 增加了 performance_schema 和 information_schema 資料庫。正如我們在上週的文章中看到的那樣，information_schema 中的資料表包含有關資料表、插件、分割區、程序清單、狀態和全域變數的統計資料。顧名思義，performance_schema 的資料表可用於提高 MySQL 執行個體的效能。如何做到這一點將成為今天的主題。就像上一篇文章一樣，我們將使用 Navicat Premium 來示範如何執行各種查詢。
簡明摘要
Performance Schema 是一種用於監控 MySQL 伺服器在較低層級執行的工具。Performance Schema 的儲存引擎名稱為「performance_schema」，以便輕鬆地將其與其他儲存引擎區分開來。擁有自己的引擎能令存取有關伺服器執行的資訊時，將對伺服器效能的影響減到最少。此外，它使用檢視或臨時資料表，以降低永久磁碟儲存的使用量。最後，記憶體分配會在伺服器啟動時全部完成，因此不需要再次重新分配記憶體或調整其大小，這能大大地提高效能。
從 MySQL 5.6.6 開始，Performance Schema 預設為啟用。在該版本之前，預設為停用。你可以使用以下語句驗證其狀態：
如果需要啟用它，可以隨時 --performance-schema=ON 旗標來啟動伺服器。
現在，讓我們了解 performance_schema 的一些實際用途。
互斥鎖（Ｍutex）和執行緒（Thread）的速成課程
互斥鎖（Mutex）是在程式碼中使用的同步機制，用於強制在特定時間只有一條執行緒可以存取某些公共資源。這些資源可以說是被互斥鎖「保護」。「Mutex」這個詞語本身是「mutual exclusion」的縮寫，亦是「Mutual variable」的非正式縮寫。在 MySQL 中，它是 InnoDB 用於表示和強制執行對內部記憶體資料結構的獨佔存取鎖的低層級物件。以下是它如何運作：
當鎖定已取得後，任何其他程序、執行緒等將被阻止取得相同的鎖定。在 InnoDB 中，多條執行緒存取共用的資料結構。InnoDB 將這些存取與其自己的互斥鎖和讀寫鎖同步。當在伺服器中執行的兩條執行緒（例如，兩個使用者階段作業同時執行一個查詢）需要存取相同的資源（例如檔案、緩衝區或某些資料）時，這兩條執行緒將相互競爭，因此取得互斥鎖鎖定的第一個查詢將導致另一個查詢等待直至第一個查詢完成並解鎖互斥鎖。如果第一條執行緒需要很長時間才能完成，那麼它可能會延誤其他程序的執行。
一些有用的查詢
所有互斥鎖都列在 Performance Schema 的 mutex_instances 資料表中，這對調查效能瓶頸非常有幫助。而 mutex_instances.LOCKED_BY_THREAD_ID 欄和 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 欄對於調查效能瓶頸或死鎖非常重要。以下是如何使用它們：
假設 thread 1 停滯在等待一個互斥鎖。
你可以判斷執行緒正在等待的什麼：
假設查詢結果顯示執行緒正在等待在 events_waits_current.OBJECT_INSTANCE_BEGIN 找到的 mutex A.
你可以判斷哪個執行緒持有 mutex A：
假設查詢結果顯示是 thread 2 持有 mutex A，如 mutex_instances.LOCKED_BY_THREAD_ID 所示。
你可以使用此查詢查看 thread 2 正在進行的動作：
總結
在今天的文章中，我們學習了如何使用 Performance Schema 來診斷 MySQL 8 中的瓶頸和/或死結。有一個更簡單的方法是使用 Navicat Monitor。我們將會在下次探索這個軟體。它有一個查詢分析器，可以顯示所有正在執行的查詢的摘要資訊，並能輕鬆地偵測到死鎖，例如兩個或多個查詢互相永久封鎖。
