锁等待超时需先查INNODB_TRX定位LOCK WAIT事务，再通过INNODB_LOCK_WAITS找到阻塞源，用PROCESSLIST确认SQL，最后KILL线程终止；预防需优化索引、缩小事务粒度、避免长事务及不一致加锁顺序。
查看当前被阻塞的事务和锁等待
锁等待超时（Lock wait timeout exceeded）本质是某个事务在等另一把未释放的锁，等太久就报错。第一步不是重启或杀进程，而是先看清谁在等、谁在占——用 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 查实时状态。
-
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED;能看到所有活跃事务，重点关注TRX_STATE = 'LOCK WAIT'的行，记下它的TRX_ID和TRX_MYSQL_THREAD_ID - 再查
INNODB_LOCK_WAITS关联blocking_trx_id，就能定位到“卡住别人”的那个事务 ID - 最后通过
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = ?找出对应线程的INFO（即 SQL），确认它执行了什么语句、卡在哪一步
快速终止阻塞源事务（慎用但有效）
确认是某个长事务或未提交事务（比如忘了 COMMIT 或 ROLLBACK）在持锁不放，最直接的解法就是手动终结它。注意：这不是“杀连接”，而是杀事务对应的线程，避免影响其他正常查询。
- 用
KILL [thread_id]终止，例如：KILL 12345;
- 不要用
KILL CONNECTION除非明确要断开整个客户端连接；KILL默认就是终止该线程的当前操作（含回滚未完成事务） - MySQL 5.7+ 支持
KILL QUERY [thread_id]只中断当前语句，不杀事务，适合调试阶段试探性使用 - 如果线程处于
Sleep状态但TRX_STATE仍是ACTIVE，大概率是应用端没正确关闭事务，需同步检查代码逻辑
预防锁等待：事务粒度与索引是否到位
很多锁等待问题不是突发的，而是长期积累的设计隐患。两个高频原因：事务包得太宽、WHERE 条件没走索引导致全表扫描加锁。
- UPDATE/DELETE 语句必须确保
WHERE中的字段有有效索引，否则 InnoDB 会升级为表级意向锁甚至行锁扩散——用EXPLAIN看type是否为range/ref，避免ALL - 事务中不要混杂非数据库操作（如 HTTP 请求、文件读写），否则事务空转时间拉长，锁持有期被动延长
- 避免在事务里执行
SELECT ... FOR UPDATE后长时间不更新，尤其不要在循环里反复加锁却不提交 - 设置合理
innodb_lock_wait_timeout（默认 50 秒），太短掩盖问题，太长拖垮业务响应；线上建议设为 30–60 秒并配合监控告警
高并发下锁冲突的典型模式识别
有些锁等待不是单点故障，而是模式化竞争，比如秒杀场景的库存扣减、订单号生成器、计数器更新。这类问题光看单次锁等待日志看不出规律，得结合慢日志和业务行为分析。
- 检查慢查询日志中是否集中出现相同
UPDATE模板（如UPDATE goods SET stock = stock - 1 WHERE id = ?），且Rows_examined远大于 1 → 说明索引失效或存在间隙锁竞争 - 多个事务按不同顺序更新同一组主键（如事务 A 更新
(1,2)，事务 B 更新(2,1)），极易触发死锁；可通过SHOW ENGINE INNODB STATUS\G中的LATEST DETECTED DEADLOCK区域验证 - 使用
SELECT ... FOR UPDATE时，务必按主键/唯一索引顺序访问，避免人为制造锁顺序不一致
真正难处理的不是单次超时，而是那种每小时固定时段密集发生的锁等待——那往往意味着业务逻辑和数据库访问模式存在结构性冲突，得从接口设计或分库分表层面动刀，而不是只调参数或杀线程。
