# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
`synch/mutex/innodb/aurora_lock_thread_slot_futex` イベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。詳細については、[MySQL リファレンス](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html)の *InnoDB ロック*を参照してください。
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 2
## 待機時間が増加する原因の可能性
複数のデータ操作言語 (DML) ステートメントが同じ行に同時にアクセスしようとしています。
## アクション
確認できる他の待機イベントに応じて、異なるアクションをお勧めします。
**Topics**
+ [この待機イベントを担当する SQL 文を見つけて応答します。](#ams-waits.waitsynch.actions.id)
+ [ブロッキングセッションを見つけて対応する](#ams-waits.waitsynch.actions.blocker)
### この待機イベントを担当する SQL 文を見つけて応答します。
Performance Insights を使用して、この待機イベントの原因になっている SQL ステートメントを特定します。以下の戦略を検討して下さい。
+ 行のロックが永続的な問題である場合は、オプティミスティックロックを使用するようにアプリケーションを書き直すことを検討してください。
+ 複数行のステートメントの使用。
+ ワークロードを異なるデータベースオブジェクトに分散します。パーティショニングによって、これを行うことができます。
+ `innodb_lock_wait_timeout` パラメータの値をチェックしてください。これは、タイムアウトエラーを生成する前にトランザクションが待機する時間を制御します。
Performance Insights を使用したトラブルシューティングの便利な概要については、ブログ記事 [Performance Insights を使用した Amazon Aurora MySQL ワークロードの分析](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/) を参照してください。
### ブロッキングセッションを見つけて対応する
ブロッキングセッションがアイドルかアクティブかを確認します。また、セッションがアプリケーションからかのものか、またはアクティブユーザーからのものであるかを調べます。
ロックを保持しているセッションを識別するには、`SHOW ENGINE INNODB STATUS` を実行します。次の例は サンプル出力を示しています。
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
または、次のクエリを使用して、現在のロックの詳細を抽出することもできます。
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
セッションを特定する際、次のようなオプションが含まれます。
+ アプリケーションの所有者またはユーザーにお問い合わせください。
+ ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「[セッションやクエリの終了](mysql-stored-proc-ending.md)」を参照してください。
ブロックトランザクションの識別の詳細については、*MySQL リファレンスマニュアル*の [InnoDB トランザクションの使用とロック情報](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html)を参照してください。