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