如何快速定位 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 STATUS\G只保留最近一次死锁详情，不适合监控场景
哪些 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的突增。
