sql 报表数据倾斜本质是某些键值数据量远超其他，导致计算任务集中；分桶是从存储层预防倾斜最直接有效的手段，需选高基数键、合理设桶数并配合命中分桶键的查询写法。
SQL 报表出现数据倾斜，本质是某些键值的数据量远超其他，导致计算任务集中在少数节点，拖慢整体响应。分桶（Bucketing）不是万能解药，但它是从存储层就控制分布、预防倾斜最直接有效的手段之一。
选对分桶键：避开低基数陷阱
分桶键若基数太低，比如只有几个固定状态码或枚举值，再设 128 个桶也只用上 3–5 个，数据必然扎堆。真实案例中，用 status（仅 0 /1/2）做分桶键，32 个桶实际只写入 3 个 Tablet，查询并行度形同虚设。
- 优先选主键或高唯一性字段，如 trade_id、order_no、user_id
- 避免用时间字段（如 day）单独分桶——它天然按天聚集，容易造成“新数据全挤在最新桶”
- 可通过
SELECT COUNT(DISTINCT col) FROM table快速验证候选字段基数是否足够（建议 > 桶数 × 3）
复合分桶键：应对热点用户或高频 ID
单靠 user_id 仍可能倾斜——头部用户行为记录占总量 70%，哈希后还是打到同一桶。这时可叠加扰动因子，让同一用户的数据分散到多个桶。
- 常用组合：SUBSTR(user_id, -2) + MONTH(register_time)，既保留业务语义，又引入变化
- 注意总长度不超过 36 字节，否则影响前缀索引效率
- 不推荐用
RAND()直接参与分桶定义（无法保证写入与查询时哈希一致），它更适合运行时“加盐”场景
桶数量设置：匹配集群规模与数据量
桶太少，并行度上不去；桶太多，小查询要扫一堆空桶，元数据开销反而上升。没有固定公式，但有实用参考线：
- 单表日增 1 亿行以上 → 建议 64–256 桶
- 集群计算节点数在 10–30 台 → 桶数尽量接近节点数的整数倍（如 16、32、64）
- StarRocks 中，每个 Tablet 默认副本数为 3，桶数 × 副本数 ≈ 总 Tablet 数，需确保不超过集群元数据承载能力（一般单 BE 建议≤1000 Tablet）
配合查询写法：让分桶真正起效
建好分桶表，不代表查询自动受益。必须让 WHERE 或 JOIN 条件命中分桶键，引擎才能跳过无关桶。
- 查询带
WHERE user_id = ?→ 可精准路由到 1 个或少量 Tablet - 查询用
WHERE SUBSTR(user_id, -2) = '12'→ 若分桶键含该字段，仍可剪枝 - JOIN 时两表分桶键一致且类型相同 → 可触发 Bucket Shuffle Join，避免全局 Shuffle
- 避免在分桶键上做函数转换（如
WHERE UPPER(user_id) = 'ABC'），会失效分桶剪枝
