synch/mutex/innodb/trx_sys_mutex - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

synch/mutex/innodb/trx_sys_mutex

当存在大量事务处理的大量数据库活动时,会发生 synch/mutex/innodb/trx_sys_mutex 事件。

相关引擎版本

以下引擎版本支持此等待事件信息:

  • Aurora MySQL 版本 2 和 3

上下文

在内部,InnoDB 数据库引擎使用可重复的读取隔离级别和快照来提供读取一致性。这为您提供了创建快照时数据库的时间点视图。

在 InnoDB 中,所有更改都将在数据库到达后立即应用到数据库,无论它们是否已提交。这种方法意味着,如果没有多版本并发控制 (MVCC),连接到数据库的所有用户都会看到所有更改和最新的行。因此,InnoDB 需要一种方法来跟踪更改,以了解必要时要回滚的内容。

为此,InnoDB 使用了一个事务系统 (trx_sys) 来跟踪快照。事务系统执行以下操作:

  • 跟踪撤消日志中每行的事务 ID。

  • 使用一个名为 ReadView 的内部 InnoDB 结构,以帮助确定哪些事务 ID 对于快照可见。

等待次数增加的可能原因

任何需要对事务 ID 进行一致和受控处理(创建、读取、更新和删除)的数据库操作都会生成从 trx_sys 到互斥锁的调用。

这些调用发生在三个函数中:

  • trx_sys_mutex_enter – 创建互斥锁。

  • trx_sys_mutex_exit – 释放互斥锁。

  • trx_sys_mutex_own – 测试是否拥有互斥锁。

InnoDB 性能架构工具跟踪所有的 trx_sys 互斥锁调用。追踪包括但不限于,在数据库启动或关闭、回滚操作、撤消清理、行读取访问和缓冲池加载时管理 trx_sys。具有大量事务的高数据库活动导致 synch/mutex/innodb/trx_sys_mutex 出现在主要等待事件之列。

有关更多信息,请参阅 MySQL 文档中的使用性能架构监控 InnoDB 互斥锁等待

操作

根据等待事件的原因,我们建议采取不同的操作。

确定导致事件的会话和查询

通常,具有中等到大量负载的数据库都会有等待事件。如果性能最佳,等待事件可能是可以接受的。如果性能不佳,请检查数据库花费最多时间的位置。查看导致最高负载的等待事件。了解是否可以优化数据库和应用程序以减少这些事件。

要在 Amazon Web Services Management Console 中查看 Top SQL(主要 SQL)图表
  1. 通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/

  2. 在导航窗格中,选择 Performance Insights

  3. 选择一个数据库实例。将为该数据库实例显示性能详情控制面板。

  4. Database load(数据库负载)图表中,选择 Slice by wait(按等待切片)。

  5. Database load(数据库加载)图表下,选择 Top SQL(主要 SQL)。

    该图表列出了负责加载的 SQL 查询。排在列表前面的负载负有最大的责任。为了解决瓶颈,请关注这些语句。

有关使用性能详情进行故障排除的有用概览,请参阅博客文章利用性能详情分析 Amazon Aurora MySQL 工作负载

检查其他等待事件

检查与 synch/mutex/innodb/trx_sys_mutex 等待事件相关的其他等待事件。执行此操作可以提供有关工作负载性质的更多信息。大量事务可能会降低吞吐量,但是工作负载也可能使此变得必要。

有关如何优化事务的更多信息,请参阅 MySQL 文档中的优化 InnoDB 事务管理