Lock wait timeout exceeded是事务等待锁超时被MySQL主动终止，需查INNODB_TRX中trx_started超1分钟且trx_query为空的长事务，并联查INNODB_LOCK_WAITS定位blocking_trx_id后KILL阻塞源。
这不是SQL执行慢，也不是数据库卡死，而是你的事务在等锁，等满innodb_lock_wait_timeout（默认50秒）后被MySQL主动终止——真正该揪出来的是那个“开了不提交、占着锁不放”的事务。
查INNODB_TRX找挂尸事务
报错SQL本身可能几毫秒就跑完，问题出在它前面排队等锁。关键不是看谁报错了，是看谁一直没提交：
- 运行
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND trx_started < DATE_SUB(NOW(), INTERVAL 60 SECOND)，重点盯trx_started超过1分钟的记录 - 检查
trx_query是否为空（说明事务空挂着），或内容是不是SLEEP(30)、HTTP调用、日志写入这类非DB操作 - 拿
trx_mysql_thread_id去比对SHOW PROCESSLIST，如果对应线程状态是Sleep且Time很大（比如2000+），八成就是它 - Spring应用尤其注意：
@Transactional方法里调了RPC但没设超时，或catch异常后忘了rollback()，事务就一直开着
联查INNODB_LOCK_WAITS确认阻塞链
单看INNODB_TRX只能知道“谁没提交”，但不知道“谁被它挡住了”。必须定位到具体的阻塞关系：
- 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+更推荐
SELECT * FROM sys.innodb_lock_waits，字段名更直白，waiting_pid/blocking_pid直接对应线程ID -
blocking_query为空不等于安全——可能刚执行完UPDATE就卡住，还没发下一条语句 - 真正该
KILL的是blocking_pid对应的线程，不是报错的那个等待者
别急着改innodb_lock_wait_timeout
调大这个值只是把“等50秒失败”变成“等300秒失败”，既不减少锁持有时间，也不缓解竞争：
- 全局修改
SET GLOBAL innodb_lock_wait_timeout = 120只对新连接生效，当前连接照旧 - 设成600秒后用户要卡满10分钟才失败，体验比立刻报错还差
- 真要用，仅限特定批量任务会话里临时设：
SET SESSION innodb_lock_wait_timeout = 90，执行完立刻恢复 - 误KILL掉
User为system user的主从同步线程，可能引发主从延迟甚至数据不一致
批量UPDATE/DELETE容易触发锁扩散
这类操作常因子查询或无索引字段导致全表扫描，进而锁住大量行：
- 例如
UPDATE t SET status=1 WHERE id IN (SELECT id FROM t2 WHERE x=1)，若t2.x没索引，子查询慢 → 主查询锁行久 → 其他事务排队超时 - 确保所有
WHERE、JOIN、IN子句里的字段都有索引 - 避免在事务里循环单条更新，改用
INSERT ... ON DUPLICATE KEY UPDATE或分页处理（每次500行） - 确认没在事务里混用
SELECT FOR UPDATE和后续DML，这会让锁提前且持久
最常被忽略的一点：SHOW ENGINE INNODB STATUS\G末尾的LATEST DETECTED DEADLOCK段落必须检查——如果为空，才是纯锁等待；如果有内容，说明MySQL已自动回滚过一个事务，那背后可能是反复发生的死锁，而不是表面看到的单次超时。
