快速定位mysql锁等待和死锁需查INNODB_TRX中LOCK WaiT事务、INNODB_LOCK_WAITS找阻塞源头，并开启innodb_print_all_deadlocks捕获死锁日志；注意SHOW ENGINE INNODB STATUS仅保留最后一次死锁详情。
如何快速定位 MySQL 中的锁等待和死锁
高并发下出现响应变慢或事务超时，大概率是锁等待堆积或死锁触发。MySQL 本身不主动暴露锁状态，必须靠 INforMATION_SCHEMA 和日志配合排查。
- 查当前锁等待：
select * FROM INformatION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT'; - 查阻塞源头（谁在持锁）：
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;结合
blocking_trx_id关联INNODB_TRX表里的TRX_ID找到持有锁的事务 - 看死锁日志：开启
innodb_print_all_deadlocks = ON后，死锁信息会写入错误日志（error_log），不是 slow log 或 general log - 注意：
SHOW ENGINE INNODB STATUSG只保留最近一次死锁详情，不适合监控场景
哪些 SQL 容易引发行锁升级为表锁或间隙锁冲突
不是所有 UPDATE 或 delete 都只锁匹配行；索引类型、查询条件是否走索引、是否含范围条件，都会影响锁粒度。
- 无索引字段上的
WHERE条件 → 全表扫描 → 每行加记录锁 + 间隙锁，等效于隐式表锁 -
SELECT ... FOR UPDATE在唯一索引上等值查询 → 只锁匹配行；但用非唯一索引或范围（如age > 25）→ 锁住对应间隙，可能阻塞其他插入 -
INSERT ... ON DUPLICATE KEY UPDATE会先加插入意向锁，再尝试获取唯一键上的记录锁；若多个事务同时插入相同ON DUPLICATE键，极易因间隙锁重叠导致死锁 - 显式事务中执行
UPDATE后未及时COMMIT或ROLLBACK→ 锁长期持有，放大等待链
避免死锁的关键设计与参数调整
死锁无法完全杜绝，但可通过访问顺序统一、事务粒度控制和隔离级别降级大幅降低概率。
- 所有业务逻辑按固定顺序访问多张表（如总是先
orders再order_items），避免交叉加锁 - 单事务内尽量减少 SQL 数量，避免在事务中调用外部服务或做复杂计算
- 将
innodb_lock_wait_timeout设为较小值（如 10–30 秒），让锁等待早失败，而不是无限挂起 - 确认业务可接受的前提下，把隔离级别从
REPEATABLE READ降到READ COMMITTED：后者不启用间隙锁（除外键和唯一检查），显著减少锁冲突 - 避免在高频更新字段上建二级索引——每次更新都要维护索引树，增加锁竞争点
线上死锁发生后，除了 kill 还能做什么
直接 KILL 事务 ID 是最快止血方式，但治标不治本；更关键的是拿到现场快照，还原路径。
- 死锁发生瞬间，立刻执行：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 10;查看最近活跃事务及其 SQL（
TRX_QUERY字段） - 结合应用日志中的 trace_id 或用户 ID，反查该事务完整执行链路（ORM 日志、SQL 打点）
- 对高频死锁的 SQL，用
EXPLAIN FORMAT=TRADITIONAL确认是否走了预期索引；必要时加FORCE INDEX固定执行计划 - 如果死锁集中在某张表的某几个字段组合上，考虑拆分热点行（如用
shard_key分散更新压力）或引入缓存层暂存中间状态
真正难处理的从来不是死锁本身，而是那些没被日志捕获、自动回滚后无声消失的锁等待——它们持续消耗连接池，最终拖垮整个数据库。所以监控不能只盯死锁数，更要盯 INNODB_ROW_LOCK_TIME_AVG 和 Threads_running 的突增。