ClickHouse ORDER BY：将高基数列置于首位是否合理？

MergeTree的ORDER BY决定了数据的物理存储布局，稀疏主键索引构建在数据颗粒（granule）的边界上，核心目标是通过匹配查询的过滤条件，最小化需要扫描的颗粒数量。针对高基数列（如user_id、order_id）是否适合放在ORDER BY首位的问题，结合原理和生产实践解答如下：

1. 高基数本身是ORDER BY的问题，还是随机性才是核心？ #

高基数本身不是问题，值的随机性才是核心矛盾：

• 若高基数列是有序分布（如自增用户ID、连续生成的订单ID），排序后同ID的数据会集中存储，颗粒内数据局部性好，稀疏索引能精准定位到目标颗粒，过滤效率极高。
• 若高基数列是随机分布（如UUID、无规律哈希值），排序后数据完全分散，每个颗粒会包含大量不同的ID值，稀疏索引无法有效过滤，查询时几乎需要扫描全表，同时数据局部性差会导致压缩率暴跌。

2. 是否存在推荐将高基数列放在首位的场景？ #

存在，当核心查询模式以单实体的等值/范围查询为主时，高基数有序列放在ORDER BY首位是最优选择，典型场景包括：

• 用户中心类表：核心查询是按user_id过滤单个用户的全量行为、订单、资产记录，将user_id放首位后，同一用户的所有数据会集中在连续颗粒中，查询时只需扫描少量颗粒，效率远超时间列开头的布局。
• CDC变更表：这类表经常需要按业务主键（如order_id、product_id）查询全量变更历史，主键通常是有序高基数列，放在ORDER BY首位能让同主键的变更记录集中存储，大幅提升回溯查询的效率。
• 多租户隔离表：按tenant_id（高基数有序）排序，每个租户的数据集中存储，租户专属查询能精准定位到对应颗粒，避免扫描其他租户的数据。

3. 与压缩性能和数据局部性的权衡？ #

权衡结果完全取决于高基数列的分布特性：

有序高基数列场景 #

• 数据局部性：同ID的数据集中存储，颗粒内数据相似度高，压缩算法（如LZ4、ZSTD）能获得更高的压缩率，节省存储成本。
• 索引效率：等值查询能直接定位到目标ID对应的颗粒，扫描量极小，查询延迟低。
• 潜在 trade-off：如果同时存在全局时间范围查询（如统计全平台近7天的用户行为），由于时间数据分散在各个ID的颗粒中，需要扫描更多颗粒，这类查询的效率会下降。

随机高基数列场景 #

• 数据局部性：排序后数据完全分散，颗粒内包含大量不同的随机值，数据相似度极低，压缩率会大幅下降，存储成本飙升。
• 索引效率：稀疏索引无法发挥过滤作用，查询时几乎要扫描全表，完全失去索引的意义。
• 权衡结论：这种场景下没有任何收益，绝对不推荐将随机高基数列放在ORDER BY首位。

MergeTree ORDER BY 设计实操指导 #

1. 先判断高基数列的分布特性：优先区分是有序（自增ID、业务主键）还是随机（UUID、无规律哈希），仅有序高基数列适合放在ORDER BY前列。
2. 匹配核心查询模式：
   • 若核心查询是单实体查询，优先将实体ID（有序高基数）放ORDER BY首位，后续搭配时间等辅助列（如ORDER BY (user_id, event_time)）。
   • 若核心查询是全局时间统计，优先将时间列放首位，高基数列可通过二级索引补充（如INDEX user_id_idx user_id TYPE bloom_filter()）。
3. 二级索引补全场景：如果两种查询模式都很频繁，可采用「时间列开头的主ORDER BY + 高基数列二级索引」的方案，平衡两类查询的效率。
4. 实测验证：用EXPLAIN查看查询的颗粒扫描数，通过system.parts表对比不同方案的压缩率（compressed_size/uncompressed_size），根据实际数据选择最优布局。

内容的提问来源于stack exchange，提问作者Mohamed Hussain S