键的真实作用
在 MPP 与列存引擎里，事实表的主键更多是语义约束而非物理索引，真正影响性能的是排序键、分布键与分区键。选型原则是把高频等值过滤列放在排序键前缀，范围过滤列紧随其后；分布键选高基数且取值均匀的列以避免数据倾斜。不同引擎能力差别明显，Doris、ClickHouse 支持显式排序键，Hive 更多依赖分区与文件内部排布，具体以对应版本文档为准。
基本信息
| 语义主键 | 业务唯一键，约束数据不重复 |
|---|---|
| 排序键 | 常过滤、常关联的列组合 |
| 分布键 | 高基数、分布均匀，避免倾斜 |
| 分区键 | 日期类列，支撑分区裁剪 |
| 引擎差异 | 能力不同，以版本手册为准 |
典型使用场景
- 事实表按日期分区、按常用维度排序，提升扫描裁剪效率
- 大表频繁关联时调整分布键，减少跨节点数据搬运
- 去重场景用唯一键约束配合去重逻辑双重保障
- 排查查询变慢：确认过滤条件是否命中排序键前缀
- 数据倾斜排查：确认分布键是否集中在少数取值上
排序键与分布键
排序键与分布键
-- Doris 明细模型：排序键放在过滤高频的列上
CREATE TABLE fact_order (
dt date,
order_id varchar(64),
user_id bigint,
amount decimal(18,2)
)
ENGINE = OLAP
DUPLICATE KEY(dt, order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 32;
-- 排序键前缀顺序决定裁剪效果
-- 等值过滤列在前，范围过滤列紧随其后键类型对照
| 键类型 | 选择依据 | 选错的表现 |
|---|---|---|
| 分区键 | 日期等时间列 | 分区数过多或裁剪失效 |
| 排序键 | 过滤与关联高频列 | 全表扫描，查询变慢 |
| 分布键 | 高基数且取值均匀 | 数据倾斜，个别节点成瓶颈 |
| 语义主键 | 业务唯一标识 | 重复数据无法被发现 |
排序键的收益来自前缀匹配：把日期放在第一位后，只有带日期条件的查询才能有效裁剪，单独使用后面的过滤列效果有限。
分布键一旦确定，改造成本较高，通常需要重建表并重导数据，因此应在建模阶段依据真实查询模式决定，而不是先建后调。