查看当前被阻塞的事务和锁等待
锁等待超时（
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时，务必按主键/唯一索引顺序访问，避免人为制造锁顺序不一致
真正难处理的不是单次超时，而是那种每小时固定时段密集发生的锁等待——那往往意味着业务逻辑和数据库访问模式存在结构性冲突，得从接口设计或分库分表层面动刀，而不是只调参数或杀线程。
