17370845950

“Lock wait timeout exceeded”是事务等待锁超时（默认50秒）被中止的错误，非死锁；常见于长事务、无索引更新或应用未提交；可通过INNODB_TRX等表定位阻塞源并KILL终止。

MySQL 中出现 “Lock wait timeout exceeded” 是什么情况

这是 MySQL 在等待行锁或表锁超时后抛出的错误，典型错误信息是：ERROR 1205 (40001): Lock wait timeout exceeded; try restarting transaction。它不等于死锁，而是事务在排队等锁时等太久（默认 50 秒，由 innodb_lock_wait_timeout 控制）被主动中止。

常见诱因包括：长事务未提交、UPDATE/DELETE 语句没走索引导致全表扫描加锁、应用端开启事务后迟迟不执行 COMMIT 或 ROLLBACK。

• 检查当前阻塞链：运行

  SELECT * FROM information_schema.INNODB_TRX;

  查看正在运行的事务及其状态
• 定位锁冲突源头：配合

  SELECT * FROM information_schema.INNODB_LOCK_WAITS;

  和

  SELECT * FROM information_schema.INNODB_LOCKS;

  （注意 MySQL 8.0+ 已移除 INNODB_LOCKS，改用 performance_schema.data_locks）
• 快速释放锁：对长时间运行的 TRX_STATE = 'RUNNING' 且 TRX_STARTED 很早的事务，可用 KILL TRX_MYSQL_THREAD_ID 终止

如何识别和确认发生了真正的死锁

MySQL 检测到死锁后会自动选择一个事务作为“牺牲者”并回滚它，同时向客户端返回错误：ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction。这个错误本身是 MySQL 主动干预的结果，不是系统卡死。

关键点在于：只有至少两个事务互相持有对方需要的锁，并形成闭环等待，才会触发死锁检测器（每秒运行一次）。

• 查看最近死锁日志：执行

  SHOW ENGINE INNODB STATUS\G

  ，重点关注 LATEST DETECTED DEADLOCK 区域，里面会显示两个事务各自的 SQL、加锁类型（RECORD LOCKS）、等待的索引、以及谁被选为 victim
• 死锁不一定发生在相同表：跨表更新顺序不一致（如事务 A 先更新 orders 再更新 inventory，事务 B 反过来）极易引发
• 唯一索引 vs 普通索引影响加锁范围：对非唯一条件做 UPDATE，InnoDB 可能加间隙锁（GAP LOCK），扩大锁粒度，增加死锁概率

避免死锁和减少锁等待的实操策略

预防比排查更重要。核心思路是减少锁持有时间、统一访问顺序、缩小锁粒度。

• 事务尽量短：所有 DML 操作完成后立即 COMMIT，不要在事务里做 HTTP 调用、文件读写等耗时操作
• 按固定顺序访问多张表：比如约定总是先操作 users 表，再操作 orders 表，避免交叉加锁
• 确保 WHERE 条件命中索引：没有索引的 UPDATE 会升级为表级意向锁，极大提高冲突概率；可用 EXPLAIN 验证执行计划
• 必要时显式加锁控制：对热点行，用 SELECT ... FOR UPDATE 提前加锁，但要确保后续一定有对应 UPDATE，否则空占锁
• 调整超时参数需谨慎：增大 innodb_lock_wait_timeout 只是掩盖问题，可能让阻塞更久；减小它可更快暴露设计缺陷，但不宜低于 10 秒

应用层如何安全重试死锁事务

收到 ERROR 1213 后不能简单原样重放 SQL——必须重放整个事务逻辑，且要防范重复执行副作用（比如扣款两次）。

推荐做法是把事务封装为幂等单元，例如用业务单号 + 状态机控制：

• 在事务开始前，先 INSERT INTO tx_log (tx_id, status) VALUES (?, 'pending') ON DUPLICATE KEY UPDATE status = status，利用唯一索引防止重复初始化
• 事务主体中更新业务表的同时，把 tx_log.status 改为 'done'
• 捕获 1213 错误后，不盲目重试，而是查 tx_log 确认是否已成功；若为 'done' 则直接返回，否则重试整个事务块
• 避免在重试逻辑里 sleep 随机时间——MySQL 死锁检测是抢占式的，延迟重试并不能降低概率，反而延长整体延迟

真正难处理的不是死锁本身，而是长事务 + 无索引查询 + 多表交叉更新这三者叠加——这种组合会让锁行为变得极难预测，日志里也看不出明显模式。