# synch/mutex/innodb/trx\$1sys\$1mutex
<a name="ams-waits.trxsysmutex"></a>

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

**Topics**
+ [

## 相关引擎版本
](#ams-waits.trxsysmutex.context.supported)
+ [

## 上下文
](#ams-waits.trxsysmutex.context)
+ [

## 等待次数增加的可能原因
](#ams-waits.trxsysmutex.causes)
+ [

## 操作
](#ams-waits.trxsysmutex.actions)

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

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

## 上下文
<a name="ams-waits.trxsysmutex.context"></a>

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

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

为此，InnoDB 使用了一个事务系统 (`trx_sys`) 来跟踪快照。事务系统执行以下操作：
+ 跟踪撤消日志中每行的事务 ID。
+ 使用一个名为 `ReadView` 的内部 InnoDB 结构，以帮助确定哪些事务 ID 对于快照可见。

## 等待次数增加的可能原因
<a name="ams-waits.trxsysmutex.causes"></a>

任何需要对事务 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 互斥锁等待](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html)。

## 操作
<a name="ams-waits.trxsysmutex.actions"></a>

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

**Topics**
+ [

### 确定导致事件的会话和查询
](#ams-waits.trxsysmutex.actions.identify)
+ [

### 检查其他等待事件
](#ams-waits.trxsysmutex.actions.action1)

### 确定导致事件的会话和查询
<a name="ams-waits.trxsysmutex.actions.identify"></a>

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

**要在 AWS 管理控制台 中查看 Top SQL（主要 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.trxsysmutex.actions.action1"></a>

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

有关如何优化事务的更多信息，请参阅 MySQL 文档中的[优化 InnoDB 事务管理](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)。