synch/mutex/innodb/buf_pool_mutex
当线程在 InnoDB 缓冲池上获取锁定以访问内存中的页面时，将发生 synch/mutex/innodb/buf_pool_mutex 事件。
相关引擎版本
以下引擎版本支持此等待事件信息：
-
Aurora MySQL 版本 2
上下文
buf_pool 互斥锁是保护缓冲池的控制数据结构的单个互斥锁。
有关更多信息，请参阅 MySQL 文档中的使用性能架构监控 InnoDB 互斥锁等待
等待次数增加的可能原因
这是特定于工作负载的等待事件。synch/mutex/innodb/buf_pool_mutex 显示在主要等待事件中的常见原因包括以下各项：
-
缓冲池不够大，无法容纳工作数据集。
-
工作负载更加特定于数据库中特定表中的某些页面，从而导致缓冲池中发生争用。
操作
根据等待事件的原因，我们建议采取不同的操作。
确定导致事件的会话和查询
通常，具有中等到大量负载的数据库都会有等待事件。如果性能最佳，等待事件可能是可以接受的。如果性能不佳，请检查数据库花费最多时间的位置。查看导致最高负载的等待事件，并了解是否可以优化数据库和应用程序以减少这些事件。
在 AWS 管理控制台中查看主要的 SQL 图表
通过以下网址打开 Amazon RDS 控制台：https://console.aws.amazon.com/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 与 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 指标以监控状态变量。有关更多信息，请参阅发布自定义指标。
