TiDB 业务查询出现热点 Region，单节点 CPU 持续打满如何排查优化

🪐 TiDB 技术问题
1

某线上业务使用 TiDB v6.5 集群，集群配置 3 个 PD、6 个 TiDB Server、9 个 TiKV 节点，业务核心表 order_trans 存储交易订单数据，主键为自增 BIGINT 类型 id。 业务高峰期出现以下现象：

  1. 其中一台 TiKV 节点 CPU 长期维持 95% 以上，其余 TiKV 节点 CPU 仅 20%~30%，集群负载严重不均衡；
  2. 前端下单接口响应从平均 10ms 飙升至 200ms+，频繁出现慢查询告警；
  3. Grafana 监控看到 order_trans 表对应的单个 Region 读写 QPS 突破 2w，其余 Region 几乎无流量；
  4. 尝试手动执行 split region 分裂分区后，短时间负载均衡，半小时后又重新出现热点。

补充背景

  1. 业务写入逻辑：每秒新增 1500 条订单，全部是自增主键顺序插入；
  2. 表结构仅主键索引 PRIMARY KEY (id)，无其他分区、无 shard 索引；
  3. 集群调度参数为默认配置，未调整 Region 分裂、迁移相关阈值。

需解决问题

  1. 分析该热点 Region 产生的根本原因；
  2. 给出可落地的长期优化改造方案（分表结构改造、集群参数调优两类）；
  3. 简述临时应急处理步骤，保障高峰期业务可用。
2

结合架构、数据特征、写入逻辑、监控现象综合判定：

  1. 自增主键导致写入热点（核心根因） order_trans 主键为自增 BIGINT，订单持续顺序插入，新数据的 id 永远单调递增，所有写入请求都会落到同一个末尾 Region，形成单 Region 读写热点，对应监控里单 Region QPS 2w、其余 Region 无流量。
  2. Region 分裂无法根治热点 手动 split region 只是物理拆分 Region，但自增 ID 依然持续向后追加，新写入数据很快又填满新的末尾 Region，半小时后复现热点。
  3. 数据分布 & 索引单一加剧问题 表仅主键索引、无打散字段，TiDB 无法基于其他维度做数据分片；默认调度参数下，Region 分裂、负载迁移策略无法抵消强顺序写入带来的天然热点。
  4. TiKV 负载倾斜 热点 Region 固定落在某一台 TiKV 节点，该节点 CPU 跑满 95%，其余节点空闲，进而导致下单接口延迟飙升、慢查询频发。
3

你看能不能拉出个临时表，建表的时候用auto_random，然后把数据导过去，最后交换表名这样子

4

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。