本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
synch/mutex/innodb/buf_pool_mutex
當執行緒已對 InnoDB 緩衝集區取得鎖定來存取記憶體中的頁面時，synch/mutex/innodb/buf_pool_mutex 事件便會發生。
相關的引擎版本
下列引擎版本支援這個等待事件資訊：
-
Aurora MySQL 第 2 版
Context
buf_pool 互斥是單一互斥，其會保護緩衝集區的控制資料結構。
如需詳細資訊，請參閱 MySQL 文件中的使用效能結構描述監控 InnoDB 互斥等待
等待變多的可能原因
這是工作負載特定的等待事件。synch/mutex/innodb/buf_pool_mutex 出現在最高等待事件之間的常見原因包括：
-
緩衝集區不夠大，無法容納工作資料集。
-
工作負載更特定於來自資料庫中特定資料表的特定頁面，從而導致緩衝集區中的爭用。
動作
根據等待事件的原因，我們會建議不同的動作。
識別造成事件的工作階段和查詢
通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。
在 AWS 管理主控台中檢視最高 SQL 圖表
前往 https://console.aws.amazon.com/rds/
，開啟 Amazon RDS 主控台。 -
在導覽窗格中，選擇 Performance Insights (績效詳情)。
-
選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。
-
在 Database load (資料庫負載) 圖表中，選擇 Slice by wait (依等待建立配量)。
-
在 Database load (資料庫負載) 圖表下方，選擇 Top SQL (最高 SQL)。
此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。
如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章利用績效詳情分析 Amazon Aurora MySQL 工作負載
使用績效詳情
此事件與工作負載相關。您可以使用績效詳情執行下列動作：
-
從應用程式日誌或相關來源識別等待事件開始的時間，以及工作負載在該段時間是否有任何變更。
-
識別負責此等待事件的 SQL 陳述式。檢查查詢的執行計劃，以確定這些查詢已最佳化，並使用適當的索引。
如果負責等待事件的最高查詢與相同的資料庫物件或資料表相關，請考慮分割該物件或資料表。
建立 Aurora 複本
您可以建立 Aurora 複本來提供唯讀流量。您也可以使用 Aurora Auto Scaling 來處理讀取流量的突增。務必在 Aurora 複本上執行排定的唯讀任務和邏輯備份。
如需更多詳細資訊，請參閱 Amazon Aurora Auto Scaling with Aurora 複本。
檢查緩衝集區大小
查看指標 innodb_buffer_pool_wait_free，檢查緩衝集區大小是否足以處理工作負載。如果此指標的值很高且持續增加，這表示緩衝集區的大小不足以處理工作負載。如果 innodb_buffer_pool_size 已正確設定，則 innodb_buffer_pool_wait_free 的值應該很小。如需詳細資訊，請參閱 MySQL 文件中的 Innodb_buffer_pool_wait_free
如果資料庫執行個體具有足夠的記憶體，可供工作階段緩衝區和作業系統任務使用，請增加緩衝區集區大小。如果沒有，請將資料庫執行個體變更為較大的資料庫執行個體類別，以取得可配置給緩衝集區的額外記憶體。
注意
Aurora MySQL 會根據設定的 innodb_buffer_pool_size 自動調整 innodb_buffer_pool_instances 的值。
監控全域狀態歷史記錄
透過監控狀態變數的變更率，您可以在資料庫執行個體上偵測鎖定或記憶體問題。開啟全域狀態歷史記錄 (GoSH)，如果尚未開啟的話。如需 GoSh 的詳細資訊，請參閱管理全域狀態歷史記錄。
您也可以建立自訂 Amazon CloudWatch 指標來監控狀態變數。如需詳細資訊，請參閱發佈自訂指標。
