本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# synch/mutex/innodb/buf\$1pool\$1mutex
<a name="ams-waits.bufpoolmutex"></a>

當執行緒已對 InnoDB 緩衝集區取得鎖定來存取記憶體中的頁面時，`synch/mutex/innodb/buf_pool_mutex` 事件便會發生。

**Topics**
+ [相關的引擎版本](#ams-waits.bufpoolmutex.context.supported)
+ [Context](#ams-waits.bufpoolmutex.context)
+ [等待變多的可能原因](#ams-waits.bufpoolmutex.causes)
+ [動作](#ams-waits.bufpoolmutex.actions)

## 相關的引擎版本
<a name="ams-waits.bufpoolmutex.context.supported"></a>

下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 2 版

## Context
<a name="ams-waits.bufpoolmutex.context"></a>

`buf_pool` 互斥是單一互斥，其會保護緩衝集區的控制資料結構。

如需詳細資訊，請參閱 MySQL 文件中的[使用效能結構描述監控 InnoDB 互斥等待](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)。

## 等待變多的可能原因
<a name="ams-waits.bufpoolmutex.causes"></a>

這是工作負載特定的等待事件。`synch/mutex/innodb/buf_pool_mutex` 出現在最高等待事件之間的常見原因包括：
+ 緩衝集區不夠大，無法容納工作資料集。
+ 工作負載更特定於來自資料庫中特定資料表的特定頁面，從而導致緩衝集區中的爭用。

## 動作
<a name="ams-waits.bufpoolmutex.actions"></a>

根據等待事件的原因，我們會建議不同的動作。

**Topics**
+ [識別造成事件的工作階段和查詢](#ams-waits.bufpoolmutex.actions.identify)
+ [使用績效詳情](#ams-waits.bufpoolmutex.actions.action1)
+ [建立 Aurora 複本](#ams-waits.bufpoolmutex.actions.action2)
+ [檢查緩衝集區大小](#ams-waits.bufpoolmutex.actions.action3)
+ [監控全域狀態歷史記錄](#ams-waits.bufpoolmutex.actions.action4)

### 識別造成事件的工作階段和查詢
<a name="ams-waits.bufpoolmutex.actions.identify"></a>

通常，具有中等至重大負載的資料庫會有等待事件。如果效能是最佳的，則等待事件可能是可以接受的。如果效能不是最佳的，則檢查資料庫在何處花費最多時間。查看造成最高負載的等待事件，並了解您是否可以最佳化資料庫和應用程式，以減少這些事件。

**在 AWS 管理主控台中檢視最高 SQL 圖表**

1. 前往 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)，開啟 Amazon RDS 主控台。

1. 在導覽窗格中，選擇 **Performance Insights** (績效詳情)。

1. 選擇資料庫執行個體。即會顯示該資料庫執行個體的績效詳情儀表板。

1. 在 **Database load** (資料庫負載) 圖表中，選擇 **Slice by wait** (依等待建立配量)。

1. 在 **Database load** (資料庫負載) 圖表下方，選擇 **Top SQL** (最高 SQL)。

   此圖表會列出負責負載的 SQL 查詢。位於清單頂端者負最大責任。若要解決瓶頸，請專注於這些陳述式。

如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。

### 使用績效詳情
<a name="ams-waits.bufpoolmutex.actions.action1"></a>

此事件與工作負載相關。您可以使用績效詳情執行下列動作：
+ 從應用程式日誌或相關來源識別等待事件開始的時間，以及工作負載在該段時間是否有任何變更。
+ 識別負責此等待事件的 SQL 陳述式。檢查查詢的執行計劃，以確定這些查詢已最佳化，並使用適當的索引。

  如果負責等待事件的最高查詢與相同的資料庫物件或資料表相關，請考慮分割該物件或資料表。

### 建立 Aurora 複本
<a name="ams-waits.bufpoolmutex.actions.action2"></a>

您可以建立 Aurora 複本來提供唯讀流量。您也可以使用 Aurora Auto Scaling 來處理讀取流量的突增。務必在 Aurora 複本上執行排定的唯讀任務和邏輯備份。

如需更多詳細資訊，請參閱 [使用 Amazon Aurora 自動擴展搭配 Aurora 複本](Aurora.Integrating.AutoScaling.md)。

### 檢查緩衝集區大小
<a name="ams-waits.bufpoolmutex.actions.action3"></a>

查看指標 `innodb_buffer_pool_wait_free`，檢查緩衝集區大小是否足以處理工作負載。如果此指標的值很高且持續增加，這表示緩衝集區的大小不足以處理工作負載。如果 `innodb_buffer_pool_size` 已正確設定，則 `innodb_buffer_pool_wait_free` 的值應該很小。如需詳細資訊，請參閱 MySQL 文件中的 [Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free)。

如果資料庫執行個體具有足夠的記憶體，可供工作階段緩衝區和作業系統任務使用，請增加緩衝區集區大小。如果沒有，請將資料庫執行個體變更為較大的資料庫執行個體類別，以取得可配置給緩衝集區的額外記憶體。

**注意**  
Aurora MySQL 會根據設定的 `innodb_buffer_pool_size` 自動調整 `innodb_buffer_pool_instances` 的值。

### 監控全域狀態歷史記錄
<a name="ams-waits.bufpoolmutex.actions.action4"></a>

透過監控狀態變數的變更率，您可以在資料庫執行個體上偵測鎖定或記憶體問題。開啟全域狀態歷史記錄 (GoSH)，如果尚未開啟的話。如需 GoSh 的詳細資訊，請參閱[管理全域狀態歷史記錄](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)。

您也可以建立自訂 Amazon CloudWatch 指標來監控狀態變數。如需詳細資訊，請參閱[發佈自訂指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。