TiDB作为分布式关系型数据库，采用Region作为数据调度的最小单位，每个Region默认存储一段连续的键值范围数据，当Region的数据量或者访问流量达到阈值时，就会触发Split操作拆分成多个更小的Region，以此实现负载分散。
TiDB Region Split 基础原理
TiDB的Region Split分为两种类型，一种是数据量触发的拆分，另一种是流量触发的热点拆分。数据量拆分主要保证单个Region的大小不会过大，避免调度和迁移时消耗过多资源。热点拆分则是针对访问频率过高的Region，通过拆分让请求分散到不同的TiKV节点上，降低单节点压力。
默认拆分阈值说明
TiDB的Region Split相关阈值可以通过系统变量或者配置文件调整，以下是默认的阈值规则：
| 拆分类型 | 默认阈值 | 说明 |
|---|---|---|
| 数据量拆分 | 96MB | 单个Region的数据大小达到96MB时，会自动触发拆分，拆分成两个大小相近的Region |
| 热点拆分（读流量） | 每60秒读请求超过20000次 | 统计周期内Region的读请求频率达到阈值，会触发热点拆分 |
| 热点拆分（写流量） | 每60秒写请求超过20000次 | 统计周期内Region的写请求频率达到阈值，会触发热点拆分 |
这些阈值可以通过修改TiKV的配置文件调整，对应的配置项如下：
[region-split] # 数据量拆分阈值，单位MB size-threshold = 96 # 热点拆分的流量统计周期，单位秒 hot-region-update-interval = 60 # 热点拆分的流量阈值，单位请求数/周期 hot-region-flow-threshold = 20000
手动干预Region拆分的时机
虽然TiDB会自动处理Region Split，但在部分场景下自动拆分无法满足需求，需要手动介入，常见的干预时机包括以下几种：
1. 业务预期会出现热点
如果业务有明确的递增主键写入场景，比如订单表使用自增ID作为主键，新写入的数据都会集中在最后一个Region，自动拆分的速度可能跟不上写入速度，导致短时间内出现严重热点。这种场景下可以在业务上线前手动拆分热点Region，提前分散负载。
手动拆分Region的命令示例如下，需要连接到TiDB集群执行：
-- 查看当前表的Region分布，找到热点Region的ID SHOW TABLE test_table REGIONS; -- 手动拆分指定Region，指定拆分的键位置 SPLIT TABLE test_table BETWEEN (1000) AND (2000) REGIONS 4;
2. 自动拆分滞后导致性能下降
如果监控发现某个Region的流量已经远超阈值，但自动拆分没有及时触发，或者拆分后新的Region仍然集中在同一个节点，导致节点CPU、磁盘IO使用率过高，业务延迟上升，此时可以手动执行拆分操作，快速分散负载。
3. 跨机房部署的负载均衡需求
如果TiDB集群采用多机房部署，自动拆分后的Region可能分布不合理，比如多个热点Region都集中在同一个机房的节点上，此时可以手动拆分Region后，配合调度命令将新的Region迁移到不同机房的节点，实现跨机房的负载均衡。
4. 批量导入数据场景
执行大批量数据导入时，短时间内会产生大量写入流量，自动拆分的频率可能不足以应对，容易导致导入过程中热点问题。可以在导入前手动预拆分目标表的Region，减少导入过程中的热点产生。
手动干预的注意事项
手动拆分Region时需要注意以下几点，避免操作带来负面影响：
- 拆分键的选择要合理，尽量让拆分后的Region负载均匀，避免拆分后仍然出现新的热点。
- 不要频繁手动拆分，拆分操作本身会消耗一定的系统资源，过于频繁的拆分会影响集群正常性能。
- 手动拆分后需要观察一段时间，确认新的Region分布符合预期，负载已经分散到不同的节点。
- 如果修改了默认的拆分阈值，需要同步调整监控告警规则，避免遗漏真正的热点问题。
可以通过以下SQL查看Region的流量情况，判断拆分效果：
-- 查看最近一段时间的热点Region SELECT * FROM information_schema.tikv_hot_regions WHERE flow_type = 'write' ORDER BY flow DESC LIMIT 10;
合理设置Region Split阈值，在合适的时机手动干预，能够有效避免TiDB集群的热点问题，保障业务的稳定运行。实际使用中需要结合业务的流量特征，灵活调整策略，不要盲目修改默认配置。
TiDBRegion_Split热点拆分阈值手动干预修改时间：2026-07-05 14:24:25