“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 <code>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 死锁检测是抢占式的，延迟重试并不能降低概率，反而延长整体延迟
真正难处理的不是死锁本身，而是长事务 + 无索引查询 + 多表交叉更新这三者叠加——这种组合会让锁行为变得极难预测，日志里也看不出明显模式。
