SSTable 中布隆过滤器必须用 std::vector 而非 std::bitset，因其支持动态 resize、连续内存布局便于 mmap 和序列化，且避免 mmap 下构造函数调用问题；哈希应选 MurmurHash3_64 配合多种子或双哈希法，k 取 3~4；filter 存为独立 filter_block（非 footer），压缩独立，查询时须先查 index block range 再解压。
为什么 SSTable 里布隆过滤器必须用 std::vector<uint8_t></uint8_t> 而不是 std::bitset
因为 SSTable 是持久化结构，布隆过滤器要序列化到磁盘并支持 mmap 随机读取。std::bitset 大小在编译期固定，无法按实际 key 分布动态调整位图长度；而 std::vector<uint8_t></uint8_t> 可以按需 resize，并且内存布局连续、无 padding，直接映射为字节数组写入文件即可。另外，mmap 后的只读内存页不能有构造函数调用，std::bitset 的默认初始化行为在 mmap 场景下不可控。
怎么选哈希函数：不能用 std::hash<:string></:string> 直接当多个哈希
std::hash 是单哈希，布隆过滤器需要 k 个独立哈希（通常 k=3~7）。硬拷贝同一个 hash 结果做多次判断会大幅升高误判率。正确做法是用一个高质量种子哈希（如 MurmurHash3 或 CityHash）配合 k 个不同种子，或用双哈希法：h1(key) 和 h2(key) 推出 h_i = (h1 + i * h2) % m（m 是位图总长度）。SSTable 场景下推荐 MurmurHash3_64，它速度快、分布均匀、对短 key（如 RocksDB 常见的 8~32 字节 key）特别友好。
- 避免用
std::hash+ 模运算生成多哈希：不同 key 的模结果容易聚集 - 种子数建议固定为 3 或 4，太多哈希轮次会拖慢查询，且对误判率改善边际递减
- 哈希输出必须截断到 64 位以内，再对位图长度
m取模，否则高位信息丢失
布隆过滤器怎么跟 SSTable 文件一起存：放在 footer 还是单独 block？
RocksDB 和 LevelDB 都把布隆过滤器作为独立的 filter_block 存在 data block 之后、footer 之前。这样设计是为了：① 可以 mmap 整个 filter block 一次加载，无需解析整个 SSTable；② filter block 自带自己的 offset/size 元信息，便于跳过；③ 多个 data block 可共享一个 filter block（比如每个 block 单独建 filter，或按 key range 合并建），灵活适配压缩策略。不要把它塞进 footer——footer 空间极小（通常 48 字节），且解析 footer 本身就要先读最后几个字节，放 filter 会破坏局部性。
- filter block 格式建议用「length-prefixed」：每个 filter 数据前写 4 字节 length，方便跳读
- 如果 SSTable 开启了 compression（如 Snappy），filter block 必须单独压缩，不能和 data block 混压——否则查 key 不存在时还得解压整个 block
- 写入时 filter block 放在文件末尾靠前位置，footer 中记录其 offset 和 size，确保 footer 总是在最后 48 字节
查询时怎么避免 false positive 导致的无效 data block 解压？
布隆过滤器只负责回答「key 可能存在」或「key 绝对不存在」。一旦 filter 返回 true，必须进一步检查 data block 的 index block 中该 key 是否真实存在（通过二分查找 block 内部的 key range），而不是直接解压 data block。很多实现在这里偷懒：filter 说可能有，就立刻解压 data block 去找，结果发现 key 不在那个 block 的 range 内——白花了 IO 和 CPU。
立即学习“C++免费学习笔记（深入）”；
- 务必先查 index block 的 key range：若
key block_limit_key，直接跳过该 block - 只有 range 包含 key 且 filter 返回 true，才去解压对应 data block 并做内部查找
- 注意：index block 本身也可以带小型布隆过滤器（meta-filter），但实践中很少用，代价高、收益低
布隆过滤器真正起效的地方，不是“查到了”，而是“一票否决”——它省掉的是磁盘 IO 和解压开销。但这一票否决的前提，是你没在 filter 之后又做一堆无效操作。
