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

`synch/mutex/innodb/trx_sys_mutex` イベントは、大量のトランザクションで高いデータベースアクティビティがある場合に発生します。

**Topics**
+ [関連するエンジンバージョン](#ams-waits.trxsysmutex.context.supported)
+ [Context](#ams-waits.trxsysmutex.context)
+ [待ち時間増加の考えられる原因](#ams-waits.trxsysmutex.causes)
+ [アクション](#ams-waits.trxsysmutex.actions)

## 関連するエンジンバージョン
<a name="ams-waits.trxsysmutex.context.supported"></a>

この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2 および 3

## Context
<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` からミューテックスに呼び出しを行います。

これらの呼び出しは、次の 3 つの関数内で発生します。
+ `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 Mutex 待機をモニタリングする](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 マネジメントコンソール で上位 SQL チャートを表示するには**

1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。

1. ナビゲーションペインで、[**Performance Insights**] を選択します。

1. DB インスタンスを選択します。その DB インスタンスの Performance Insights ダッシュボードが表示されます。

1. **データベースロード**で、**待機でスライス**を選択します。

1. **データベースロード**グラフで、**上位の SQL**を選択します。

   グラフには、ロードの原因となる SQL クエリがリストされます。リスト上部にあるクエリに、最も責任があります。ボトルネックを解決するには、これらのステートメントに注目してください。

Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した 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)を参照してください。