tidb_tikvclient_backoff_seconds_count 和 TiKV_approximate_region_size 告警怎么排查？怎么优化？

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境
【TiDB 版本】
生产环境总是报这两个告警，怎么排查？怎么优化？
tidb_tikvclient_backoff_seconds_count
TiKV_approximate_region_size

2
  • 开启 AUTO_RANDOM / SHARD_ROW_ID_BITS
  • PD 调大 split 速度
  • TiKV 线程池调大
  • 业务避免大事务、长事务
  • TiKV 节点 CPU 不能长期 > 70%
3

你的告警 99% 是以下原因：

  1. 表没有分片，Region 过大
  2. 写入热点集中在少数 Region
  3. TiKV 负载高导致请求重试

最快修复（10 分钟内见效）

  1. 对大表执行 手动预分裂
  2. 对自增主键表开启 SHARD_ROW_ID_BITS
  3. 确认 TiKV 节点负载，必要时扩容 1 个 TiKV
4

排查一下大region，这个一般都是 Region 异常 / 热点 / 大 Region。

5

另外标有没有做分区呢

6

这个回答怎么感觉这么AI呢 :joy:

7

表没有分片或者有太大的热点region吧

8

默认的阈值设置的太小
一般这个告警没啥影响，主要看其他指标

9

这个调整有什么推荐的值吗

10
  1. tidb_tikvclient_backoff_seconds_count
  • 含义 ：这个指标统计了 TiDB 节点（作为客户端）在向 TiKV 节点发起请求时，因遇到各种错误（如服务器正忙、区域未准备好、写入冲突等）而触发“回退”（backoff）机制的总时长。
  • 解读 ：当这个值持续升高或频繁告警时，说明 TiKV 集群处理请求的能力不足，导致 TiDB 的请求被拒绝或延迟，需要等待重试。这通常是 TiKV 节点负载过高、资源不足或存在热点 的直接体现。
  1. TiKV_approximate_region_size
  • 含义 ：这个指标表示 TiKV 中每个 Region 的近似大小。TiKV 会自动将 Region 进行分裂（split）和合并（merge），以维持一个相对均衡的大小（默认目标大小约为 96MB）。
  • 解读 ：如果这个值持续过大（例如远超 100MB），说明 Region 的分裂可能不及时，或者存在写入热点，导致单个 Region 的数据量急剧增长。过大的 Region 会影响负载均衡、备份恢复和故障恢复的效率。
11
  1. 打开 TiDB Dashboard ，首先通过 Key Visualizer 确认是否存在明显的读写热点。
  2. 检查 TiKV 节点的资源监控 （CPU、IO），判断是否是资源瓶颈。
  3. 根据发现的问题，从 业务（SQL/表结构） 和 运维（扩容/配置） 两个层面入手进行优化。
12

你直接设置成5000或者关闭也行

13

好的，学习了