# synch/cond/innodb/row\$1lock\$1wait
`synch/cond/innodb/row_lock_wait` イベントは、あるセッションが更新のために行をロックし、別のセッションが同じ行を更新しようとしたときに発生します。詳細については、MySQL ドキュメントの「[InnoDB Locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html)」を参照してください。
## サポート対象エンジンバージョン
この待機イベント情報は、以下のエンジンバージョンでサポートされています。
+ Aurora MySQL バージョン 3
## 待機時間が増加する原因の可能性
複数のデータ操作言語 (DML) ステートメントが同じ行に同時にアクセスしようとしています。
## アクション
確認できる他の待機イベントに応じて、異なるアクションをお勧めします。
**Topics**
+ [この待機イベントを担当する SQL 文を見つけて応答します。](#ams-waits.row-lock-wait.actions.id)
+ [ブロッキングセッションを見つけて対応する](#ams-waits.row-lock-wait.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 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; 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_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_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_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
セッションを特定する際、次のようなオプションが含まれます。
+ アプリケーションの所有者またはユーザーにお問い合わせください。
+ ブロッキングセッションがアイドル状態の場合は、ブロッキングセッションを終了することを検討してください。このアクションは、長いロールバックをトリガーする可能性があります。セッションの終了方法については、「[セッションやクエリの終了](mysql-stored-proc-ending.md)」を参照してください。
ブロックトランザクションの識別の詳細については、MySQL ドキュメントの「[Using InnoDB transaction and locking information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html)」を参照してください。