lock wait timeout exceeded 是锁等待超时而非死锁，需通过 innodb_trx 和 innodb_lock_waits 定位并 kill blocking_trx_id 对应的阻塞事务，而非报错线程；调大 innodb_lock_wait_timeout 仅掩盖问题，不解决根本。
这不是死锁，是事务在等锁超时被MySQL主动终止；必须先定位并处理阻塞源，而不是重试或调大超时时间。
怎么看报错是不是锁等待超时而非死锁
错误信息里明确写着 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部分——如果为空或时间对不上，就不是刚发生的死锁 - 应用层重试后仍频繁报这个错，大概率是某个长事务或未提交事务在持续霸占锁
怎么快速定位正在霸占锁的未提交事务
别先看慢 SQL 或怀疑索引——报错的那条 UPDATE 往往执行飞快，只是前面卡在等锁。关键看 INNODB_TRX 里那些“开了很久却没结束”的事务。
运行：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_started <p>重点关注：</p>
-
trx_started超过 1 分钟的记录 -
trx_query为空（说明事务空挂着） -
trx_query在执行耗时操作（比如SLEEP()、HTTP 调用、大循环） - 拿
trx_mysql_thread_id去比对SHOW PROCESSLIST，看对应线程状态是不是Sleep且Time很大——八成就是它
怎么确认谁在等谁、该 KILL 哪个线程
盲目 KILL 报错线程只是让当前请求失败，阻塞源还在，下个请求照常超时。真正该处理的是阻塞源。
联查锁等待关系：
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+ 更推荐用：
SELECT * FROM sys.innodb_lock_waits;
字段更直观：waiting_pid / blocking_pid。确认 blocking_query 是调试残留、死循环还是业务异常卡住，再决定是否 KILL。
特别注意：
- 别用
KILL干掉主库同步线程（User字段为system user） - 别干掉关键定时任务或连接池保活线程
- 优先
KILLblocking_pid对应的线程，不是waiting_pid
调整 innodb_lock_wait_timeout 有什么实际作用
它只是改“等多久就放弃”，不解决“谁在占着不放”。设成 300 秒，只是让问题延迟暴露，不是修复。
可用场景：
- 会话级临时调低（如
SET SESSION innodb_lock_wait_timeout = 5;）可用于快速复现问题，逼出隐藏长事务 - 全局修改需重启或
SET GLOBAL（但新连接才生效），生产环境慎用 - 如果调大后错误变少，说明你掩盖了应用层事务控制缺陷，不是优化
真正要盯的是事务边界是否清晰、RPC 是否设了超时、异常路径有没有 rollback、Spring 的 @Transactional 是否嵌套不当——这些比调参数重要得多。
