lock wait timeout是锁被长期霸占导致的报错结果，真正卡死业务的是未提交事务、未走索引引发的间隙锁及sleep状态的阻塞线程。
Lock wait timeout不是超时本身导致卡死，而是卡死的结果
报错那条语句通常执行得很快，真正拖住整个业务链路的，是前面某个“开了事务却不提交”的线程。它像一扇半开的门——自己不动，也不让别人过。后续所有想改同一行（或同一索引范围）的 UPDATE/DELETE 都会被堵在门口，等满 innodb_lock_wait_timeout（默认 50 秒）后统一报错。这不是数据库慢了，是锁被长期霸占。
为什么查 SHOW PROCESSLIST 看不到阻塞源？
因为持有锁的线程状态常常是 Sleep，而不是 Query 或 Updating。它可能刚执行完一条 UPDATE 就卡在应用层：比如调了下游 HTTP 接口没设超时、RPC 调用 hang 住、或者 @Transactional 方法里 catch 了异常却忘了 rollback。
- 重点盯
Time列值很大的Sleep线程，尤其User是应用连接池用户名（如app_user）而非system user - 用
SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'RUNNING' AND UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(trx_started) > 60找运行超 1 分钟的事务 -
trx_query为空 ≠ 安全，恰恰说明它什么 SQL 都没发，纯属“占坑”
间隙锁（Gap Lock）会让卡死范围远超预期
在 REPEATABLE READ 隔离级别下，InnoDB 不只锁住你要更新的那条记录，还会锁住索引上“本该插入新记录”的间隙。比如 WHERE id BETWEEN 100 AND 200 没走索引，引擎会退化为全表扫描，顺手把整段索引间隙都锁了——结果是连 id=150 之外的其他行也更新不了。
- 用
EXPLAIN确认你的WHERE条件是否命中索引；没命中，就等于主动申请表级锁粒度 - 批量更新时避免
IN (SELECT ...)子查询，容易触发全表扫描+间隙锁膨胀 - 临时切到
READ COMMITTED隔离级别可禁用间隙锁（但需评估一致性影响）
KILL 错线程会让问题立刻复现
报错日志里那个“等待失败”的事务 ID 不是你该杀的对象。真正要处理的是它的 blocking_trx_id 或 blocking_pid ——也就是那个拿着锁不放的线程。杀错人，下一个请求立刻重蹈覆辙。
- MySQL 8.0+ 直接查
sys.innodb_lock_waits，字段名更直白：blocking_pid对应SHOW PROCESSLIST中的ID - 杀之前先
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ?确认线程归属（别误杀主从同步线程） - 会话级临时调低
SET SESSION innodb_lock_wait_timeout = 5反而是好办法——能快速暴露隐藏长事务，比盲目调高更有效
真正卡死的从来不是那条报错 SQL，而是没人收尾的事务、没走索引的条件、和没被看见的间隙锁。这些点一旦漏掉一个，调再大的超时时间也只是把失败延后几秒而已。
