17370845950

快速定位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 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 的突增。