# 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)
+ [上下文](#ams-waits.bufpoolmutex.context)
+ [等待次数增加的可能原因](#ams-waits.bufpoolmutex.causes)
+ [操作](#ams-waits.bufpoolmutex.actions)

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

以下引擎版本支持此等待事件信息：
+ Aurora MySQL 版本 2

## 上下文
<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. 通过以下网址打开 Amazon RDS 控制台：[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/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 Auto Scaling 与 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)。