# synch/cond/innodb/row\$1lock\$1wait
`synch/cond/innodb/row_lock_wait` 이벤트는 한 세션이 업데이트를 위해 행을 잠그고 다른 세션이 동일한 행을 업데이트하려고 할 때 발생합니다. 자세한 내용은 MySQL 설명서의 [InnoDB 잠금](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 문을 찾아 응답합니다.
성능 개선 도우미를 사용하여 이 대기 이벤트를 담당하는 SQL 문을 식별합니다. 다음과 같은 전략을 생각해 보세요.
+ 행 잠금이 지속적으로 문제가 되는 경우 낙관적 잠금을 사용하도록 애플리케이션을 다시 작성하는 것이 좋습니다.
+ 다중 명령문을 사용합니다.
+ 서로 다른 데이터베이스 객체에 워크로드를 분산합니다. 파티셔닝을 통해 이를 수행할 수 있습니다.
+ `innodb_lock_wait_timeout` 파라미터 값을 확인하세요. 시간 초과 오류가 발생하기 전에 트랜잭션이 대기하는 시간을 제어합니다.
성능 개선 도우미를 통한 문제 해결의 개요는 블로그 게시물, [성능 개선 도우미를 통해 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)을 참조하세요.