本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# synch/cond/innodb/row\$1lock\$1wait
<a name="ams-waits.row-lock-wait"></a>

當一個工作階段已鎖定資料列進行更新，而另一個工作階段嘗試更新同一資料列時，`synch/cond/innodb/row_lock_wait` 事件便會發生。如需詳細資訊，請參閱 MySQL 文件中的 [InnoDB 鎖定](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html)。



## 支援的引擎版本
<a name="ams-waits.row-lock-wait.versions"></a>

下列引擎版本支援這個等待事件資訊：
+ Aurora MySQL 第 3 版

## 等待時間增加的可能原因
<a name="ams-waits.row-lock-wait.causes"></a>

多個資料處理語言 (DML) 陳述式正在同時存取相同的資料列。

## 動作
<a name="ams-waits.row-lock-wait.actions"></a>

我們會建議不同的動作，取決於您看到的其他等待事件。

**Topics**
+ [尋找並回應負責此等待事件的 SQL 陳述式](#ams-waits.row-lock-wait.actions.id)
+ [尋找並回應封鎖工作階段](#ams-waits.row-lock-wait.actions.blocker)

### 尋找並回應負責此等待事件的 SQL 陳述式
<a name="ams-waits.row-lock-wait.actions.id"></a>

使用績效詳情來識別負責此等待事件的 SQL 陳述式。請考慮下列策略：
+ 如果資料列鎖定是持續發生的問題，請考慮重寫應用程式以使用樂觀鎖定。
+ 使用多列陳述式。
+ 將工作負載分散到不同的資料庫物件上。您可以透過分割來執行此動作。
+ 檢查 `innodb_lock_wait_timeout` 參數的值。它控制交易在產生逾時錯誤之前等待多長時間。

如需使用績效詳情進行疑難排解的實用概觀，請參閱部落格文章[利用績效詳情分析 Amazon Aurora MySQL 工作負載](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/)。

### 尋找並回應封鎖工作階段
<a name="ams-waits.row-lock-wait.actions.blocker"></a>

判斷封鎖工作階段是閒置還是作用中。此外，了解工作階段來自應用程式還是作用中的使用者。

若要識別保留鎖定的工作階段，您可以執行 `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 文件中的[使用 InnoDB 交易與鎖定資訊](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html)。