MySQL中Updating阶段行锁等待超时的典型现象是执行UPDATE语句时突然报错“Lock wait timeout exceeded”，语句简单但耗时远超innodb_lock_wait_timeout（如50秒），本质是已获行锁却因上游事务未提交而卡在数据修改前；常见诱因包括其他事务对同一行执行SELECT...FOR UPDATE或UPDATE后长期未提交、应用开启事务后遗忘COMMIT/ROLLBACK、存储过程隐式长事务或AUTOCOMMIT=0连接未结束事务。

MySQL中Updating阶段行锁等待超时的典型现象

执行 UPDATE 语句时突然报错 Lock wait timeout exceeded; try restarting transaction，且该语句本身不复杂（比如只更新单行、有主键条件），但耗时远超 innodb_lock_wait_timeout 默认值（50秒）。这时大概率不是语句慢，而是被别的事务卡在了“Updating”阶段——即已获取行锁、正准备修改数据，却因上游事务未提交而死等。

常见诱因包括：

• 其他事务对同一行执行了 SELECT ... FOR UPDATE 或 UPDATE 后长期未提交
• 应用层开启事务后执行了部分操作，忘记 COMMIT 或 ROLLBACK
• 存储过程或触发器内隐式开启了长事务
• 使用了 AUTOCOMMIT=0 的连接，后续没显式结束事务

快速定位阻塞源头的SQL组合

核心思路是：查正在运行的事务 → 找出持有锁的线程 → 关联其 SQL 和状态。

SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_started <br> 先筛出运行时间较长的活跃事务（避免干扰瞬时事务）。

接着用这个 trx_mysql_thread_id 去查： SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ?;
看 PROCESSLIST_INFO 是否为空——为空说明当前没在执行 SQL，可能卡在锁等待或休眠；若非空，则直接看到它卡在哪条语句。

更直接的方式是关联锁视图： SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread, b.trx_query blocking_query FROM information_schema.INNODB_LOCK_WAITS w INNER JOIN information_schema.INNODB_TRX b ON b.trx_id = w.blocking_trx_id INNER JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;
这条语句能直出谁在等谁、等哪条 SQL。注意：某些 MySQL 5.7+ 版本需确保 performance_schema 开启且相关消费者已启用。

UPDATE语句在Updating阶段卡住的特殊表现

MySQL 的 “Updating” 状态（出现在 SHOW PROCESSLIST 的 State 列）意味着事务已成功加锁，并进入实际修改数据页的阶段——这一步本身极快，但如果锁被占用，它根本进不到这个状态，而会卡在 “updating” 之前的状态，如 “Waiting for table metadata lock” 或直接显示 “Locked”。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

真正显示为 “Updating” 却长时间不动，通常说明：

• 该事务已拿到行锁，但正在等其他资源（如磁盘 I/O 延迟、大 BLOB 字段写入、二级索引维护开销高）
• 表上有大量二级索引，UPDATE 导致多个索引树同步更新，期间被其他 DDL（如 ALTER TABLE）阻塞元数据锁
• 使用了 ROW_FORMAT=COMPRESSED 且页分裂频繁，导致行锁粒度临时升级为间隙锁或临键锁，扩大了锁冲突面

此时 INNODB_TRX 中的 trx_operation_state 可能为 updating，但 trx_rows_locked 和 trx_rows_modified 值长时间不变，就是线索。

避免和缓解的实操建议

• 更新前先用 SELECT ... FOR UPDATE 显式加锁并检查逻辑，比直接 UPDATE 更易暴露阻塞点
• 应用层严格控制事务边界：所有 BEGIN 必须配对 COMMIT 或 ROLLBACK，禁止跨函数/HTTP 请求持有事务
• 对高频更新字段，减少二级索引数量；必要时把 UPDATE 拆成 SELECT + UPDATE 分步，避免锁住整行太久
• 调低 innodb_lock_wait_timeout（如设为 10），让超时更快暴露问题，而不是让应用无感知地 hang 住
• 不要依赖 KILL 随意终止事务——被 kill 的事务回滚可能更慢，反而加剧锁等待链

真正难排查的，是那种“刚执行完 UPDATE 就断电/网络中断”的连接，它留下的脏事务不会自动释放锁，只能靠 DBA 主动发现并 KILL。这类场景下，information_schema.INNODB_TRX 的 trx_started 时间戳比应用日志还可靠。