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 互斥锁等待
操作
根据等待事件的原因，我们建议采取不同的操作。
确定导致事件的会话和查询
通常，具有中等到大量负载的数据库都会有等待事件。如果性能最佳，等待事件可能是可以接受的。如果性能不佳，请检查数据库花费最多时间的位置。查看导致最高负载的等待事件。了解是否可以优化数据库和应用程序以减少这些事件。
要在 AWS Management Console 中查看 Top SQL（主要 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 工作负载
检查其他等待事件
检查与 synch/mutex/innodb/trx_sys_mutex 等待事件相关的其他等待事件。执行此操作可以提供有关工作负载性质的更多信息。大量事务可能会降低吞吐量，但是工作负载也可能使此变得必要。
有关如何优化事务的更多信息，请参阅 MySQL 文档中的优化 InnoDB 事务管理
