真正危险的信号是innodb_row_lock_current_waits > 5且innodb_row_lock_time_avg > 50ms同时出现；前者反映瞬时阻塞队列长度，后者揭示平均等待延迟，二者交叉验证可精准识别活跃锁竞争。
只看 innodb_row_lock_waits 绝对值毫无意义，真正危险的信号是 innodb_row_lock_current_waits > 5 且 innodb_row_lock_time_avg > 50ms 同时出现。
怎么看当前有没有人正在排队等锁
这是判断“此刻是否卡住”的唯一硬指标。它反映的是瞬时等待队列长度，不是历史累计值。
-
innodb_row_lock_current_waits = 0：当前没有事务在等待行锁，哪怕innodb_row_lock_waits是 50 万也不用立刻处理 -
innodb_row_lock_current_waits ≥ 5：已有明显阻塞，需立即查INFORMATION_SCHEMA.INNODB_TRX找TRX_STATE = 'LOCK WAIT'的事务 -
innodb_row_lock_current_waits ≥ 20：大概率存在阻塞链，比如一个长事务持锁，后面堆了十几条 UPDATE 在等
执行命令：SHOW STATUS LIKE 'innodb_row_lock_current_waits';
为什么不能只盯 innodb_row_lock_waits 这个数
它是自 MySQL 启动以来的累计计数，重启就归零。单看这个数字，就像用“城市建城以来总车祸数”判断今天堵不堵车。
- 跑了三个月，
innodb_row_lock_waits = 1200→ 平均每天 13 次，大概率正常 - 过去 60 秒内从 10000 跳到 10150 → 增量 150，说明每分钟正发生严重争用
- 高值可能来自一次长事务拖累：它自己没释放 X 锁，导致后续 200 个事务全在
innodb_row_lock_waits里记了一笔，但实际锁持有者只有一个
真正该监控的是增长率：用 Prometheus 的 rate(mysql_global_status_innodb_row_lock_waits[1m]) * 60，或脚本定时采集差值。超过 100 次/分钟即告警。
innodb_row_lock_time_avg 比次数更能说明问题
平均等待时长直接关联业务延迟感受。即使每分钟只等 2 次，但每次卡 200ms，支付类服务已经超时。
-
innodb_row_lock_time_avg ≤ 5ms：大概率是短事务 INSERT 冲突（如无主键并发写），应用几乎无感 -
innodb_row_lock_time_avg > 50ms：索引失效或查询范围过大，比如UPDATE orders SET status='done' WHERE user_id=123没走user_id索引，实际锁了整张表的聚簇索引 -
innodb_row_lock_time_max > 1000ms：结合INNODB_TRX查trx_started最早的LOCK WAIT事务，它往往就是根因
注意：innodb_row_lock_time_avg 是总耗时 / 总次数，受极值影响大，必须和 innodb_row_lock_time_max 对着看。
交叉验证才能避开误判
孤立看任何一个指标都可能翻车：
-
innodb_row_lock_current_waits突然归零，但innodb_row_lock_waits每分钟涨 200 → 不是问题解决了，而是短事务高频抢同一行（比如订单状态轮询），锁一放一拿，队列没积压但竞争真激烈 -
innodb_row_lock_time_avg很低（3ms），innodb_row_lock_time_max却高达 800ms → 存在偶发性热点行，比如所有新订单都写入status = 'pending'的同一间隙，得查performance_schema.data_locks定位具体哪一行 -
innodb_row_lock_waits高但innodb_row_lock_current_waits始终为 0 → 锁等待太短，连进队列都不够格，优先级低于其他组合
最该立刻响应的组合永远是：innodb_row_lock_current_waits > 5 且 innodb_row_lock_time_avg > 50ms —— 这通常意味着某条 UPDATE 正反复锁住同一行或间隙，而你还没看到死锁报错，只是请求变慢了。
