2026/9/9 18:25:04
FEATURED · 精选文章 
MySQL锁等待快速排查3步从告警到止血不再等DBA【免费下载链接】CS-Base图解计算机网络、操作系统、计算机组成、数据库共 1000 张图 50 万字破除晦涩难懂的计算机基础知识让天下没有难懂的八股文 在线阅读https://xiaolincoding.com项目地址: https://gitcode.com/GitHub_Trending/cs/CS-Base锁等待又告警了订单接口 P99 从 80ms 飙到 6s连接池快满了。 凌晨两点的告警群里值班同学 了你。你打开 processlist看到一排Waiting for ... lock的会话心里大概清楚这不是玄学是有人在持锁不放。别慌下面这套排查动作熟练后几分钟就能跑完全流程。一张图看懂锁等待先别背隔离级别、锁类型那一套名词MySQL 锁等待本质上就一句话有人持着锁不放别人只能排队。分清单向排队和双向互等后面诊断就不迷路诊断的目标就是搞清楚这张图里谁持、谁等、等的是哪个索引上的哪段范围。动手诊断三条命令定位锁等待根因这时候别急着翻文档按顺序跑下面三条命令。查这个视图innodb_lock_waits 揪出阻塞源头SELECT * FROM sys.innodb_lock_waits\G;看blocking_trx_id谁持着不放和blocking_trx_started它在事务里泡了多久。判断标准很直白阻塞方是个睡了几分钟、没新 SQL 的长事务元凶就是它一堆事务排在一个阻塞方后面雪崩的源头也在这。查这个视图data_locks 看持锁明细SELECT * FROM performance_schema.data_locks\G;重点看LOCK_STATUS字段。一个事务 WAITING 的锁恰好是另一个事务 GRANTED 的锁且双方互指就是循环等待即死锁只有单向等待那是普通锁等待等释放或直接 KILL 就行。翻这份日志死锁排查的现场照片SHOW ENGINE INNODB STATUS\G;找LATEST DETECTED DEADLOCK段落它记录了死锁双方各自持有、等待的锁和最后执行的 SQL全是数据库自己拍下的现场不用猜。反复出现时拿日志里的 SQL 去对代码。对症下药先 KILL 止血再改代码治病先止血让业务先跑起来 KILL 阻塞事务拿第一步查到的阻塞方连接 ID 直接 KILL队列立刻疏通先确认它是误操作的长事务再动手。调锁超时设置把innodb_lock_wait_timeout调小让等锁请求快速失败返回而不是堆积到压垮连接池。写接口临时限流对抢同一批数据的写接口限流降级给数据库一个喘息窗口。再治病断掉锁等待的根WHERE 必须走索引没索引的 update 会锁全表详见 update 没加索引会锁全表。统一访问顺序多表、多行按固定顺序加锁从源头掐掉循环等待。缩短事务事务里别调 RPC、别发 MQ查改完尽快 commit。幂等交给唯一索引别再靠select ... for update防重详见 MySQL 死锁了怎么办。一个完整故事跑通死锁排查全流程周五晚高峰订单超时告警弹出。你 10 秒跑完 innodb_lock_waits定位到一个睡了 3 分钟的长事务KILL 掉后接口秒回。第二天翻死锁日志发现两个事务对 order_no 非唯一索引各持 next-key 锁、互相等对方插入于是把幂等校验改成唯一索引事务缩到只剩两次 DB 操作。此后一周锁等待告警再没响过。收个尾记住这三件事锁等待不可怕怕的是不知道谁在等谁——一条 innodb_lock_waits 就能回答。死锁日志是数据库自己拍下的现场照片比口述可靠得多。预防大于救火索引、顺序、短事务做到位锁等待自然少。延伸阅读MySQL 死锁了怎么办MySQL 是怎么加锁的MySQL 有哪些锁【免费下载链接】CS-Base图解计算机网络、操作系统、计算机组成、数据库共 1000 张图 50 万字破除晦涩难懂的计算机基础知识让天下没有难懂的八股文 在线阅读https://xiaolincoding.com项目地址: https://gitcode.com/GitHub_Trending/cs/CS-Base创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
MySQL锁等待快速排查3步，从告警到止血不再等DBA
MySQL锁等待快速排查3步从告警到止血不再等DBA【免费下载链接】CS-Base图解计算机网络、操作系统、计算机组成、数据库共 1000 张图 50 万字破除晦涩难懂的计算机基础知识让天下没有难懂的八股文 在线阅读https://xiaolincoding.com项目地址: https://gitcode.com/GitHub_Trending/cs/CS-Base锁等待又告警了订单接口 P99 从 80ms 飙到 6s连接池快满了。 凌晨两点的告警群里值班同学 了你。你打开 processlist看到一排Waiting for ... lock的会话心里大概清楚这不是玄学是有人在持锁不放。别慌下面这套排查动作熟练后几分钟就能跑完全流程。一张图看懂锁等待先别背隔离级别、锁类型那一套名词MySQL 锁等待本质上就一句话有人持着锁不放别人只能排队。分清单向排队和双向互等后面诊断就不迷路诊断的目标就是搞清楚这张图里谁持、谁等、等的是哪个索引上的哪段范围。动手诊断三条命令定位锁等待根因这时候别急着翻文档按顺序跑下面三条命令。查这个视图innodb_lock_waits 揪出阻塞源头SELECT * FROM sys.innodb_lock_waits\G;看blocking_trx_id谁持着不放和blocking_trx_started它在事务里泡了多久。判断标准很直白阻塞方是个睡了几分钟、没新 SQL 的长事务元凶就是它一堆事务排在一个阻塞方后面雪崩的源头也在这。查这个视图data_locks 看持锁明细SELECT * FROM performance_schema.data_locks\G;重点看LOCK_STATUS字段。一个事务 WAITING 的锁恰好是另一个事务 GRANTED 的锁且双方互指就是循环等待即死锁只有单向等待那是普通锁等待等释放或直接 KILL 就行。翻这份日志死锁排查的现场照片SHOW ENGINE INNODB STATUS\G;找LATEST DETECTED DEADLOCK段落它记录了死锁双方各自持有、等待的锁和最后执行的 SQL全是数据库自己拍下的现场不用猜。反复出现时拿日志里的 SQL 去对代码。对症下药先 KILL 止血再改代码治病先止血让业务先跑起来 KILL 阻塞事务拿第一步查到的阻塞方连接 ID 直接 KILL队列立刻疏通先确认它是误操作的长事务再动手。调锁超时设置把innodb_lock_wait_timeout调小让等锁请求快速失败返回而不是堆积到压垮连接池。写接口临时限流对抢同一批数据的写接口限流降级给数据库一个喘息窗口。再治病断掉锁等待的根WHERE 必须走索引没索引的 update 会锁全表详见 update 没加索引会锁全表。统一访问顺序多表、多行按固定顺序加锁从源头掐掉循环等待。缩短事务事务里别调 RPC、别发 MQ查改完尽快 commit。幂等交给唯一索引别再靠select ... for update防重详见 MySQL 死锁了怎么办。一个完整故事跑通死锁排查全流程周五晚高峰订单超时告警弹出。你 10 秒跑完 innodb_lock_waits定位到一个睡了 3 分钟的长事务KILL 掉后接口秒回。第二天翻死锁日志发现两个事务对 order_no 非唯一索引各持 next-key 锁、互相等对方插入于是把幂等校验改成唯一索引事务缩到只剩两次 DB 操作。此后一周锁等待告警再没响过。收个尾记住这三件事锁等待不可怕怕的是不知道谁在等谁——一条 innodb_lock_waits 就能回答。死锁日志是数据库自己拍下的现场照片比口述可靠得多。预防大于救火索引、顺序、短事务做到位锁等待自然少。延伸阅读MySQL 死锁了怎么办MySQL 是怎么加锁的MySQL 有哪些锁【免费下载链接】CS-Base图解计算机网络、操作系统、计算机组成、数据库共 1000 张图 50 万字破除晦涩难懂的计算机基础知识让天下没有难懂的八股文 在线阅读https://xiaolincoding.com项目地址: https://gitcode.com/GitHub_Trending/cs/CS-Base创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
