# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
<a name="ams-waits.io-temppoolmanager"></a>

`synch/mutex/innodb/temp_pool_manager_mutex` 待機イベントは、セッションがセッション一時テーブルスペースのプールを管理するためのミューテックスの取得を待機しているときに発生します。

**Topics**
+ [サポート対象エンジンバージョン](#ams-waits.io-temppoolmanager.context.supported)
+ [Context](#ams-waits.io-temppoolmanager.context)
+ [待機時間が増加する原因の可能性](#ams-waits.io-temppoolmanager.causes)
+ [アクション](#ams-waits.io-temppoolmanager.actions)

## サポート対象エンジンバージョン
<a name="ams-waits.io-temppoolmanager.context.supported"></a>

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

## Context
<a name="ams-waits.io-temppoolmanager.context"></a>

Aurora MySQL バージョン 3.x 以降では、`temp_pool_manager_mutex` を使用して、一時テーブルスペースプールに同時にアクセスする複数のセッションを制御します。Aurora MySQL は、永続データ用に Aurora クラスターボリュームを介してストレージを管理し、一時ファイル用にローカルストレージを管理します。セッションが Aurora クラスターボリュームに一時テーブルを作成する場合、一時テーブルスペースが必要です。

セッションが初めて一時テーブルスペースをリクエストすると、MySQL は共有プールからセッション一時テーブルスペースを割り当てます。セッションには、次のテーブルタイプで一度に最大 2 つの一時テーブルスペースを保持できます。
+ ユーザーが作成した一時テーブル
+ オプティマイザが生成した内部一時テーブル

デフォルトの `TempTable` エンジンは、次のオーバーフローメカニズムを使用して一時テーブルを処理します。
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) 制限までテーブルを RAM に保存します。
+ RAM がいっぱいになると、ローカルストレージのメモリマップファイルに移動します。
+ メモリマップされたファイルが [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) 制限に達すると、共有クラスターボリュームを使用します。

一時テーブルが RAM とローカルストレージの両方の制限を超えると、MySQL はディスク上のテーブルスペースを使用して一時テーブルを管理します。

セッションでディスク上の一時テーブルが必要な場合、MySQL は次のようになります。
+ プールで使用可能な `INACTIVE` テーブルスペースを探して再利用します。
+ `INACTIVE` スペースが存在しない場合は、10 個の新しいテーブルスペースを作成します。

セッションが切断されると、MySQL は次の操作を行います。
+ セッションの一時テーブルスペースを切り捨てます。
+ 再利用するためにプールでそれらを INACTIVE としてマークします。
+ サーバーの再起動まで現在のプールサイズを維持します。
+ 再起動後、デフォルトのプールサイズ (10 テーブルスペース) に戻ります。

## 待機時間が増加する原因の可能性
<a name="ams-waits.io-temppoolmanager.causes"></a>

この待機イベントの原因となる一般的な状況。
+ クラスターボリュームに内部一時テーブルを作成する同時セッション。
+ クラスターボリュームにユーザー一時テーブルを作成する同時セッション。
+ アクティブなテーブルスペースを使用したセッションの突然の終了。
+ 書き込み負荷の高いワークロード中のテーブルスペースプールの拡張。
+ アクセスする同時クエリ `INFORMATION_SCHEMA.`

## アクション
<a name="ams-waits.io-temppoolmanager.actions"></a>

待機イベントの原因に応じたさまざまなアクションをお勧めします。

**Topics**
+ [一時テーブルの使用状況のモニタリングと最適化](#ams-waits.io-temppoolmanager.actions.monitor)
+ [INFORMATION\$1SCHEMA を使用してクエリを確認する](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [innodb\$1sync\$1array\$1size パラメータを増やす](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [接続プールを実装する](#ams-waits.io-temppoolmanager.actions.connection_pooling)

### 一時テーブルの使用状況のモニタリングと最適化
<a name="ams-waits.io-temppoolmanager.actions.monitor"></a>

一時テーブルの使用状況をモニタリングして最適化するには、次のいずれかの方法を使用します。
+ Performance Insights の `Created_tmp_disk_tables` カウンターをチェックして、Aurora クラスター全体でディスク上の一時テーブルの作成を追跡します。
+ データベースでこのコマンドを実行して、一時テーブルの作成を直接モニタリングします。`mysql> show status like '%created_tmp_disk%'`。

**注記**  
一時テーブルの動作は、Aurora MySQL リーダーノードとライターノードで異なります。詳細については、「[Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)」を参照してください。

一時テーブルを作成するクエリを特定したら、以下の最適化ステップを実行します。
+ `EXPLAIN` を使用してクエリ実行プランを調べ、一時テーブルが作成される場所と理由を特定します。
+ クエリを変更して、可能な場合は一時テーブルの使用量を減らします。

クエリの最適化だけではパフォーマンスの問題を解決できない場合は、以下の設定パラメータの調整を検討してください。
+  [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram) – 一時テーブルの最大 RAM 使用量を制御します。
+  [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) – メモリマップされたファイルストレージの制限を設定します。
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size) – `aurora_tmptable_enable_per_table_limit` が有効になっている場合に適用されます (デフォルトでは無効)。

**重要**  
特定のクエリ条件では、設定に関係なく、常にディスク上の一時テーブルが必要になることに注意してください。`TempTable` ストレージエンジンの詳細については、「[Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/)」を参照してください。

### INFORMATION\$1SCHEMA を使用してクエリを確認する
<a name="ams-waits.io-temppoolmanager.actions.schema-queries"></a>

`INFORMATION_SCHEMA` テーブルをクエリすると、MySQL はクラスターボリュームに InnoDB 一時テーブルを作成します。各セッションには、これらのテーブルの一時テーブルスペースが必要です。これにより、同時アクセスが多い場合にパフォーマンスの問題が発生する可能性があります。

パフォーマンスを向上させるには。
+ 可能な限り `INFORMATION_SCHEMA` の代わりに `PERFORMANCE_SCHEMA` を使用します。
+ `INFORMATION_SCHEMA` を使用する必要がある場合は、これらのクエリを実行する頻度を減らします。

### innodb\$1sync\$1array\$1size パラメータを増やす
<a name="ams-waits.io-temppoolmanager.actions.sync_array"></a>

`innodb_sync_array_size` パラメータは、MySQL のミューテックス/ロック待機配列のサイズを制御します。`1` のデフォルト値は一般的なワークロードで機能しますが、これを増やすと、同時実行数が多いときにスレッドの競合を減らすことができます。

ワークロードで待機スレッドの数が増えると表示される場合。
+ ワークロード内の待機中のスレッドの数をモニタリングします。
+ スレッド調整構造を分割し、競合を減らすには、`innodb_sync_array_size` をインスタンスの vCPU 数以上に設定します。

**注記**  
RDS インスタンスで使用可能な vCPU の数を確認するには、[Amazon RDS インスタンスタイプ](https://aws.amazon.com/rds/instance-types/)の vCPU 仕様を参照してください。

### 接続プールを実装する
<a name="ams-waits.io-temppoolmanager.actions.connection_pooling"></a>

MySQL は、一時テーブルを作成する各セッションに専用のテーブルスペースを割り当てます。このテーブルスペースは、データベース接続が終了するまでアクティブのままです。リソースをより効率的に管理するには。
+ 接続プーリングを実装して、アクティブな一時テーブルスペースの数を制限します。
+ オペレーションごとに新しい接続を作成する代わりに、既存の接続を再利用します。