在某些场景中，可能会出现无法高效利用主键索引的查询。这些情况下，ClickHouse可能需要对每个列执行全表扫描，尤其是在应用WHERE子句条件时。您可使用跳数索引（data skipping index），以加速这些查询。
了解跳数索引
跳数索引使用了特定的数据结构，其核心机制如下：
功能目标：通过data part 的 granule（即预先生成的标记），跳过不符合
WHERE子句条件的data part，减少 IO 和计算量。实现方式：在
data part的granule创建轻量级索引，快速判断data part是否包含目标数据。适用场景：主键无法覆盖的列过滤、复杂表达式查询的场景。
更多跳数索引详情，请参见Use data skipping indices where appropriate。
过度使用影响
在某些情况下，跳数索引能够加速特定查询的速度，但在许多情况下，因过度使用它而产生负面影响。
性能未提升反而降低。
写入开销增加：索引构建增加写入延迟，降低数据吞吐量。
查询效率降低：若索引列与主键无统计相关性，大量data part仍被加载评估，导致系统会进行索引检查和全表扫描，导致双重开销。
表设计复杂化。
表结构臃肿：多个索引增加元数据管理复杂度，影响维护与可读性。
维护成本：索引需随数据分布变化动态调整，否则可能失效。
使用原则
使用跳数索引时，不是简单的创建索引，而是需要仔细设计才能发挥最大作用。因此，我们经常看到它们使表设计复杂化，并减慢插入性能，而很少（如果有的话）提高查询性能。以下为跳数索引的一些使用原则。
使用优先级黄金法则
主键优化先行：确保主键覆盖高频查询（建议主键列 ≤ 4-5 个）。主键最佳实践，请参见主键设计最佳实践。
次选预计算方案：使用 投影（Projections）或 物化视图预聚合高频查询数据。
最后考虑使用跳数索引。
设计原则
强相关性要求：索引列必须与主键有明确统计关联（如时序场景的时间戳与设备ID）。
高筛选率验证：索引需能跳过90%以上的数据块方有意义，否则性价比为负。
实施建议
分析验证：引入索引后，通过查询日志与
EXPLAIN分析实际跳过量。动态调整：定期评估索引有效性，随数据分布变化及时优化或删除。
更多跳数索引的最佳实践，请参见跳数索引最佳实践。