锁等待超时本质是事务卡在行锁、间隙锁或自增锁上，需三步联动定位：先查innodb_trx中trx_state='lock wait'的事务，再通过innodb_lock_waits获取blocking_trx_id，最后关联processlist查真实sql；常见根因包括索引缺失导致全表扫描加锁、事务内混入外部调用、批量insert撞自增锁。
锁等待超时不是配置调大就能解决的问题，它本质是事务卡在行锁、间隙锁或自增锁上——查不到源头，调参只会掩盖问题，甚至让连接池先崩。
怎么快速定位谁在堵路
别只看 SHOW PROCESSLIST，它不显示锁关系。真正有效的三步联动查法：
- 先查等待中的事务：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT'，重点关注trx_started时间和trx_mysql_thread_id - 再查阻塞链：
SELECT * FROM information_schema.INNODB_LOCK_WAITS，拿到blocking_trx_id（肇事者）和requested_lock_id（受害者） - 最后关联线程：
SELECT ID, USER, HOST, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID = ?，把blocking_trx_id转成线程 ID 去查真实 SQL
如果 STATE 是 Waiting for table metadata lock，说明是 DDL（比如 ALTER TABLE）在等元数据锁，得换路径查 performance_schema.metadata_locks，跟行锁无关。
为什么 UPDATE/INSERT 总卡住
常见硬伤就三个，每种都对应明确的现场特征：
-
UPDATE或DELETE没走索引：用EXPLAIN看执行计划，type是ALL就是全表扫描 → 锁成千上万行 → 别的事务一碰就等 - 事务里混了外部调用：比如 RPC、HTTP 请求、文件读写、
SLEEP()，查INNODB_TRX里trx_started和当前时间差超过 5 秒的，基本就是它 -
INSERT批量撞自增锁：MySQL 5.7 默认innodb_autoinc_lock_mode = 1，整条语句执行完才释放自增锁；高并发下排队明显，SHOW VARIABLES LIKE 'innodb_autoinc_lock_mode'确认后可考虑设为 2（需重启）
innodb_lock_wait_timeout 改多少才合适
这个参数只控制“等多久就放弃”，不解决“为什么等”。设太小（如 1 秒）会误杀正常慢事务；设太大（如 300 秒）用户卡五分钟才失败，体验更差。
- 核心接口建议设为 5 或 10：失败快，前端能及时降级或重试
- 后台批处理可设 120，但前提是事务本身不能真跑两分钟——比如避免在事务里调外部接口
-
SET innodb_lock_wait_timeout = 10只对当前会话生效；SET GLOBAL对新连接生效（截至 2026 年 8 月 3 日）
KILL 谁？为什么不能只 KILL 报错的线程
报错的线程只是“等锁失败”，真正要 KILL 的是 blocking_trx_id 对应的那个事务。
- 查出
blocking_trx_id后，转成PROCESSLIST.ID，再执行KILL ? - 否则你杀掉等锁的，锁还在，下一个请求照样卡住
- 特别注意：别 KILL
USER是system user的线程（主库同步线程）或定时任务，可能引发数据不一致
最常被忽略的是：锁等待超时发生后，持锁事务仍存活且未提交——它可能已经挂了、卡在网络调用里、或根本忘了 COMMIT，这种“空挂事务”必须人工干预，自动化脚本很难覆盖所有场景。
