我先给结论，再说明它在项目里解决什么问题。理解 minmax、set、Bloom Filter 等索引的裁剪原理和适用数据分布。ClickHouse 跳数索引为一组 granule 保存摘要，查询条件证明某些数据块不可能命中时直接跳过。它是主排序键之外的辅助裁剪手段，不像 OLTP 二级索引那样返回精确行位置。 索引有效性高度依赖数据局部性；若目标值均匀散布在每个数据块中，索引几乎无法跳过任何内容。

核心机制我会按一次真实执行过程来讲。沿着「按 granule 生成索引摘要 → 查询计算谓词范围 → 索引判断可能命中 → 跳过确定不匹配 granule → 读取剩余列并过滤」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 按 granule 生成索引摘要 跳数索引在写入时按 GRANULARITY 记录 minmax、集合、Bloom 等摘要，不保存每行位置。 查询计算谓词范围 查询条件必须被索引类型支持，函数和数据类型转换可能阻止使用。

实现细节只抓关键入口，不会整段背源码。EXPLAIN indexes=1：跳数索引命中与 granule。 system.dataskippingindices：索引定义。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

放到生产使用时，我会关注参数和验证数据。构造有序/随机分布并比较 minmax、set、Bloom 的跳过率。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「granules dropped」为主基线，记录值应满足「记录稳态基线」；同时保存 索引命中过滤率、readrows 前后差异，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。Bloom 适合等值或集合包含，不支持大小范围，且 UUID 在每个 granule 中高度分散。调整查询模型、把可范围过滤的时间/租户放进排序键，比继续放大 Bloom 参数更有效。 索引类型与谓词不匹配：索引命中过滤率：谓词匹配索引类型。 未验证 readrows 就判断索引有效：readrows 前后差异：无收益索引删除。 方案：更适合的场景：主要收益：代价与边界。 minmax：数值/时间在数据中有聚集：摘要小、范围跳过有效：随机分布时几乎无收益。 set：每 granule 低基数枚举：等值判断精确：基数超阈值会失效或膨胀。 Bloom filter：字符串等值、token 或 ngram：允许概率摘要高基数值：有假阳性且写入/存储成本较高。 选型至少带上 日增量、分区规模、查询并发、扫描行数和压缩比，并用上面的量化基线验证；