synch/cond/innodb/row_lock_wait_cond

当一个会话锁定了一个行以进行更新，而另一个会话尝试更新同一行时，将会发生 synch/cond/innodb/row_lock_wait_cond 事件。有关更多信息，请参阅 MySQL 参考中的 InnoDB 锁定。

支持的引擎版本

以下引擎版本支持此等待事件信息：

• Aurora MySQL 版本 2

等待次数增加的可能原因

多个数据操作语言 (DML) 语句同时访问相同的一行或多行。

操作

根据您看到的其他等待事件，我们建议采取不同的操作。

查找并响应负责此等待事件的 SQL 语句

使用性能详情可识别应对此等待事件负责的 SQL 语句。请考虑以下策略：

• 如果行锁定是持续存在的问题，请考虑重写应用程序以使用乐观锁。

• 使用多行语句。

• 将工作负载分散到不同的数据库对象上。您可以通过分区执行此操作。

• 检查 innodb_lock_wait_timeout 参数的值。它控制事务在生成超时错误之前需要等待多长时间。

有关使用性能详情进行故障排除的有用概览，请参阅博客文章利用性能详情分析 Amazon Aurora MySQL 工作负载。

查找并响应阻止会话

确定阻止会话处于空闲状态还是活动状态。另外，了解会话是来自应用程序还是活跃用户。

要识别持有锁的会话，您可以运行 SHOW ENGINE INNODB STATUS。下面的示例显示了示例输出。

mysql> SHOW ENGINE INNODB STATUS;

---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 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_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 参考手册中的使用 InnoDB 事务和锁定信息。