首页/数据/NoSQL 速查/ORDER BY 排序键与稀疏索引
本包目录(322 条)
MongoDB99 条Elasticsearch89 条
ClickHouse56 条
时序与列式28 条选型与架构50 条

ORDER BY 排序键与稀疏索引

ORDER BY 决定数据在 part 内的物理顺序,并生成每 index_granularity 行一条的稀疏主索引;WHERE 命中排序键前缀时可按粒度跳过数据块。

NoSQL 速查数据更新于 2026-10-12
排序键选择把高频过滤、可控基数的列放前面,时间列通常放尾部参与排序
主键声明PRIMARY KEY 必须是 ORDER BY 的前缀;不写时等于 ORDER BY
无法保证MergeTree 不保证行唯一,有序性也只在单个 part 内成立

示例

示例
-- 查询能利用排序键前缀裁剪
SELECT count() FROM metrics WHERE metric = 'cpu' AND ts >= now() - INTERVAL 1 HOUR;

-- 不命中前缀的过滤无法裁剪,只能扫描
SELECT count() FROM metrics WHERE value > 100;

-- 看主键与排序键定义
SELECT name, sorting_key, primary_key FROM system.tables WHERE table = 'metrics';
用 EXPLAIN 或 system.query_log 里的 read_rows 对比实际扫描行数,能验证排序键是否用上。

易错点

  • 把 UUID 这类高基数列放排序键前面会让索引比数据还大,裁剪收益也差
  • WHERE 条件里对排序键使用函数(如 toString(ts))会导致无法裁剪

数据来源与参考

  • ClickHouse Docs: MergeTree primary key and indexes
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌