RC等待耗时异常。资源组消耗没达到最大，前后也没有特别消耗RU的查询。突然出现一波RC等待耗时达10s+的SQL

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.4

有一个时间点SQL的RC等待耗时异常。资源组消耗不高，远没达到配额，前后也没有特别消耗RU的查询，集群的整体负载也不高。毫无预兆的突然出现一波RC等待耗时达10s+的SQL。什么原因？怎么排查

2
  • 查慢 SQL 确认 SQL 所属资源组；
  • 监控看 slot 等待耗时指标是否同步冲高；
3

top命令看下资源

4

分库分表迁移注意全局唯一ID生成方式。

5

跨版本问题源于优化器规则和存储引擎层变更。

6
  • PD 磁盘 I/O 瓶颈 ：PD 需要频繁写入 Raft 日志和元数据快照。如果 PD 所在磁盘延迟高、利用率饱和，会严重拖慢 TSO 服务。务必确认 PD 配置了高性能 SSD 并独占使用 。
7

突发尖峰第一名诱因：瞬时遗留锁触发大批量 Resolve Lock 排队，其次是 GC 批量清理锁、Region Leader 瞬时切换

8

RC（Resolve Conflict / 读时解锁）等待突然飙到 10s+，但资源组和负载都不高，这种“毫无预兆的一波”通常不是资源瓶颈，而是遇到了锁或事务冲突需要 resolve lock。常见原因：1）有大事务或长事务在某个时间点提交/回滚，读请求撞上它未清理的锁，需要等待 resolve；2）某个悲观锁事务持锁时间长，其他读要等锁；3）PD 或 TiKV 在那个时间点有 region 调度/split/merge，导致短暂的读等待。排查建议：先看 Grafana 的 TiKV-Details → 相关的 lock/resolve 面板，以及 TiDB → KV Errors 里的 lock resolve OPS 是否在那个时间点尖刺；再用 SLOW_QUERY 表或 dashboard 定位那批慢 SQL，看它们等待的 region/key 是否集中；结合 INFORMATION_SCHEMA.CLUSTER_TIDB_TRX 和 DATA_LOCK_WAITS 看当时有没有锁等待链。多数情况能定位到某个大事务或热点 key。8.5.4 版本也可以看看是否有已知的相关 issue。