lock wait timeout exceeded不是死锁，是事务等待锁超时被mysql主动终止；错误信息明确含“lock wait timeout exceeded; try restarting transaction”即可确认，而死锁报错固定为“deadlock found”，且innodb会自动回滚一个事务。
这不是死锁，是事务在等锁超时被MySQL主动扔掉；先查谁没提交，而不是调大超时时间或重试SQL。
怎么一眼区分Lock wait timeout exceeded和死锁
错误信息里明确写着 Lock wait timeout exceeded; try restarting transaction，就不是死锁。死锁报错固定是 Deadlock found when trying to get lock，且InnoDB会自动回滚一个事务。而这个错误意味着：当前事务卡在等锁，等满 innodb_lock_wait_timeout（默认50秒）后被强制终止，但**持有锁的那个事务还活着、没提交、也没报错**。
- 查日志或监控，只看到这一种报错、没伴随
Deadlock字样，基本排除死锁 - 执行
SHOW ENGINE INNODB STATUS\G，翻到LATEST DETECTED DEADLOCK部分——如果为空或时间对不上，就不是刚发生的死锁 - 应用层重试后仍频繁报这个错，大概率是某个长事务或未提交事务在持续霸占锁
用INNODB_TRX快速揪出“挂尸”事务
别先看慢SQL或索引，Lock wait timeout exceeded 的SQL往往执行飞快，只是前面卡在等锁。关键看 INNODB_TRX 里那些“开了很久却没结束”的事务：
- 运行
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_started ，重点盯 <code>trx_started超过1分钟的记录 - 检查
trx_query是否为空（说明事务空挂着），或是否在执行耗时操作（比如调外部HTTP、发邮件、SLEEP()） - 拿
trx_mysql_thread_id去比对SHOW PROCESSLIST，看对应线程状态是不是Sleep且Time很大——八成就是它 - Spring应用尤其注意：
@Transactional方法里调了RPC却没设超时，或catch异常后忘了rollback
联查INNODB_LOCK_WAITS确认谁在阻塞谁
盲目 KILL 报错线程只是让当前请求失败，阻塞源还在，下个请求照常超时。真正该处理的是阻塞源：
- MySQL 5.7/8.0通用：
SELECT r.trx_id waiting_trx_id, r.trx_query waiting_query, b.trx_id blocking_trx_id, b.trx_query blocking_query FROM INFORMATION_SCHEMA.INNODB_TRX r INNER JOIN INFORMATION_SCHEMA.INNODB_LOCK_WAITS w ON r.trx_id = w.requesting_trx_id INNER JOIN INFORMATION_SCHEMA.INNODB_TRX b ON b.trx_id = w.blocking_trx_id - MySQL 8.0+ 更推荐用
sys.innodb_lock_waits视图，字段更直观（waiting_pid/blocking_pid） - 确认
blocking_query是调试残留、死循环还是业务异常卡住，再决定是否KILL - 千万别
KILL主库同步线程（User字段为system user）或关键定时任务
调整innodb_lock_wait_timeout的真实作用
它只是改“等多久就放弃”，不解决“谁在占着不放”。设成300秒，只是让问题延迟暴露，不是修复：
- 会话级临时调低（如
SET SESSION innodb_lock_wait_timeout = 5）可用于快速复现问题，逼出隐藏长事务 - 全局修改需重启或
SET GLOBAL（但新连接才生效），生产环境慎用 - 如果调大后错误变少，说明你掩盖了应用层事务控制缺陷，不是优化
- 索引缺失可能导致锁升级（比如
UPDATE无索引走全表扫描，锁整张表），但这属于次要原因——先清掉挂着的事务，再考虑索引
最容易被忽略的一点：阻塞源事务可能根本没执行SQL，只是开了事务、做了点轻量逻辑（比如写日志、发MQ），然后卡在下游服务响应上，自己却没感知——这种“静默阻塞”最难排查，必须结合应用链路日志交叉验证。
