MPP分布式

🪐 TiDB 技术问题
1

MPP 分布式执行中，Join 数据倾斜自动打散的底层分片算法和代价判定逻辑？

2

热点行数超均值 8 倍、单点计算代价过高，启用打散；小表直接广播，不打散。

3

1、分片算法：常规数据用 JoinKey 一次 Hash 分片，热点倾斜 key 启用双层随机哈希拆分，同热点键打散至多分片多节点；
2、代价判定：优化器 CBO 预估键分布预加倾斜代价、择优广播 / Shuffle；运行时按分片行数、内存、耗时超标判定倾斜，对比打散网络损耗与并行收益，自动触发分片打散。

4

建议看下 TiDB Dashboard 的监控，特别是慢查询和 KV 耗时，能快速定位瓶颈。有具体报错贴一下，我帮你分析看。

5

这个问题可以看看官方文档的 FAQ，TiDB 在这块有比较详细的说明。方便的话贴一下具体的报错日志，方便大家帮忙定位。

6

普通数据基于关联键做哈希分片，倾斜数据采用双层随机哈希打散。优化器结合数据分布、资源开销做代价判断，运行时检测到单分片数据量、负载超标后，自动执行打散操作，小表则直接采用广播方式处理。

7

看看实际快照

1 个赞
8
  • OB MPP Join 主流两种执行：Hash Join（分布式重分发）、Broadcast Join；数据倾斜特指：某一个 Join Key 行数远超平均值，落在同一个 Worker，单任务内存打爆、Sort/Hash 算子超时、4012 查询超时（你之前 obshell 报错同类根源）。
  • 自动打散核心模块：倾斜探测器 SkewDetector + 分片重分发算子 SkewSplit Redistribute；仅作用于 Hash Join（Broadcast 无分片分发，不支持打散）。
  • 适用场景：等值 Join（A.id = B.id）；非等值 Join 无法哈希分片，无自动打散逻辑。
9

分片算法以Hash 分片为基础，倾斜时对热点 Key 做二次 Hash 分裂分片、多值倾斜用本地轮询预打散，小表场景可切换 Broadcast 广播分片；代价判定基于统计信息预判热点占比，对比普通 Shuffle、打散 Shuffle、Broadcast 三者的网络 IO+CPU + 长尾时延总代价，选择综合时延最低的方案，运行时还会依据队列负载动态兜底重打散。