Azure中哈希键、分区与索引的区别、选型及协同使用方法

一、核心区别 #

• 哈希键：仅针对分布式表，是跨计算节点的数据分配规则。通过哈希函数将同一哈希值的行分配到同一个节点，核心目的是避免数据倾斜，最大化并行查询效率。它决定了数据在集群节点间的分布位置。
• 分区：可用于分布式表、复制表，是单个节点内部的数据拆分策略。按指定列（如时间、范围）将数据拆分为多个子数据集，核心目的是减少查询扫描范围，提升过滤类查询的速度，同时简化数据归档/删除操作。
• 索引：是数据的快速检索路径，与数据的分布/分区逻辑无关，但依赖底层数据的组织方式。核心目的是加速特定查询的检索效率，不同类型的索引适配不同的查询场景。

二、选型逻辑 #

哈希键选型 #

• 优先选择查询中频繁用于JOIN、GROUP BY、DISTINCT操作的列，这样能让关联/聚合操作尽量在单个节点内完成，减少跨节点数据传输。
• 必须选基数高、值分布均匀的列，比如订单ID、用户ID；避免选基数极低的列（如性别、状态），否则会导致大量数据集中在少数节点，引发数据倾斜。

分区选型 #

• 优先选择查询中频繁作为过滤条件的列，最常见的是时间类列（如订单日期、交易时间），其次是范围型列（如金额区间、地区编码）。
• 分区粒度要平衡：粒度太细（如按小时分区）会增加元数据管理开销；粒度太粗（如按年分区）则无法有效减少扫描范围。

索引选型 #

• 聚集列存储索引：默认且推荐用于分析型场景，适合批量聚合、多列查询，能大幅压缩数据体积并提升扫描效率。
• 非聚集索引：适合点查询或高选择性的过滤查询（如按主键查询单条记录），能快速定位到目标行。
• 非聚集列存储索引：适合经常查询固定几列的场景，兼顾列存储的压缩和查询效率，同时不影响基表的索引结构。

三、协同工作示例 #

以电商订单分析场景为例，三者的协同方式如下：

1. 哈希键：选择order_id作为哈希键，确保订单数据均匀分布在所有计算节点，当与用户表（哈希键为user_id）JOIN时，同一用户的订单和用户数据会落在同一节点，避免跨节点数据传输。
2. 分区：按order_date按天分区，当查询“近7天的订单销售额”时，仅扫描7个分区的数据，无需遍历全表。
3. 索引：创建聚集列存储索引，针对批量聚合查询（如按日期统计各品类销售额），利用列存储的压缩和并行扫描能力，快速返回结果。

另一个场景：用户交易记录表

• 哈希键选user_id：同一用户的所有交易数据集中在同一节点，查询单个用户的交易明细时，仅需访问一个节点。
• 分区选transaction_date按月分区：归档历史数据时，直接删除对应月份的分区，操作高效无额外开销。
• 非聚集索引建在transaction_id上：快速定位单条交易记录，满足客服查询单笔交易的需求。

内容的提问来源于stack exchange，提问作者Alex Fernando dos Santos Silva