load base split 默认开启但阈值保守，需调低split.qps-threshold=500、split.byte-threshold=5mb/s以适配读密集场景；预切分用split table防写热点；region不merge因hot标记未失效；balance-leader平衡请求压力，balance-region平衡存储压力。
Region 热点自动分裂：Load Base Split 怎么开、怎么调
Load Base Split 是 TiKV 4.0 起内置的“自感知”热点拆分机制，它不依赖人工干预，而是靠实时读流量统计（QPS 或吞吐）触发 Region 拆分。默认已开启，但阈值保守——split.qps-threshold=3000、split.byte-threshold=30MB/s，多数生产读密集型场景根本达不到这个水位，等于形同虚设。
常见错误现象是：明明 Grafana 上看到某个 TiKV 的 read_keys 或 read_bytes 飙高，PD 却迟迟不调度，Region 数也没变。这不是 PD 失灵，而是 Load Base Split 压根没被触发。
- 读多写少场景（如报表查询、索引扫描）建议调低阈值：
split.qps-threshold=500（小表全扫常见 QPS 200–800），split.byte-threshold=5MB/s - 调整方式为 PD 配置项，需通过
pd-ctl或配置文件热更新：config set split.qps-threshold 500 - 注意：该机制只对“连续 10 秒”超阈值的 Region 生效，瞬时毛刺不会触发；且拆分后 Region 不会被 Merge（
MergeChecker会跳过 hot Region）
手动预切分 Region：什么时候该用 SPLIT TABLE，怎么避坑
Load Base Split 是“事后补救”，而预切分是“事前防御”。新建大表或批量导入前不做预切分，所有写入会打到单个 Region，瞬间压垮一个 TiKV——这是最典型的写热点起因。
使用场景很明确：建完表立刻要灌数据、TPC-C 类持续写入、主键单调递增（如 AUTO_INCREMENT）。
- 均匀切分推荐语法：
SPLIT TABLE t1 BETWEEN (0) AND (10000000) REGIONS 16，适合主键/分区键分布较均匀的场景 - 不均匀切分更精准：
SPLIT TABLE t1 BY (1000), (5000), (20000)，适用于热点 key 已知（如热门商品 ID、固定时间范围） - 关键坑：执行后返回
SCATTER_FINISH_RATIO=0.3并不意味着失败，只是 PD 还在打散中；若长期卡住，检查 TiKV 是否磁盘满、网络延迟高，或tidb_wait_split_region_finish=0导致客户端误以为已完成
为什么 Region 死活不 Merge？不是负载低了就应该合起来吗
Region Merge 是 PD 的“节能模式”，但它有硬性规避逻辑：只要 Region 被标记为 hot（哪怕当前 QPS 已回落），Merge 就会被跳过。这不是 bug，是设计使然——防止刚合并完又立刻分裂，引发震荡。
典型现象：某张表做完批量查询后，监控显示读流量归零，但 Region 数量仍远高于基线，information_schema.tikv_region_status 中 is_hot=1 字段还挂着。
- 根本原因在心跳信息：TiKV 上报的
regionheartbeat包含近期 QPS 统计，PD 依据该值判断是否 hot；即使当前无流量，历史窗口内峰值仍影响判定 - 不能强行关掉 Merge（
schedule.enable-region-merge=false是全局开关，影响所有非 hot Region），否则存储碎片化加剧，Raftstore 压力上升 - 真正可控的是“冷下来”的速度：调小 PD 的
hot-region-cache-hits-threshold（默认 3），让 hot 标记更快失效；但别设成 1，否则抖动敏感易误判
Balance-leader 和 balance-region 调度器到底在平衡什么
很多人以为“负载均衡”就是把 Region 均匀摊到每个 TiKV，其实 PD 用两个独立调度器分别管两件事：balance-leader 管请求压力，balance-region 管存储压力。二者目标不同、评分逻辑不同、甚至可能反向操作。
例如：某 TiKV 存储已 85%，但 Leader 数极少——balance-region 会往它身上搬 Peer（加重存储），而 balance-leader 同时把 Leader 往外迁（减轻请求）。结果就是这个节点磁盘快爆了，但 CPU 反而降了。
-
balance-leader分数 = 所有 Leader 对应 Region 的approximate_size之和；balance-region分数 = 所有 Peer 的approximate_size之和 - Leader 过载时优先看
tikv_details – leader_info面板，而非总 Region 数；Peer 过载则盯store_capacity_used_ratio - 若发现长期失衡，先确认是否启用了
label-property约束（如机房隔离），这类约束会直接禁用某些调度路径
Region 的 Split/Merge/调度从来不是孤立动作，它们像齿轮咬合：Load Base Split 拆得越准，balance-leader 就越容易把请求导出去；预切分铺得越早，Raftstore 就越不容易在高峰期卡住 propose wait。真正难的不是调哪个参数，而是看清当前瓶颈究竟在读、写、存储容量，还是 PD 自身的调度吞吐——这些信号都藏在 regionheartbeat 和 storeheartbeat 的原始字段里，而不是 Dashboard 的聚合曲线中。
