在数据库查询优化场景中，Bloom Filter 作为一种空间高效的概率数据结构，承担着快速判断「元素是否可能存在」的关键职责。然而，随着插入元素数量增加，传统单比特 Bloom Filter 的误判率会急剧上升，当误判率超过 10% 时，其过滤价值便大打折扣。本文深入探讨一种基于双比特编码的工程优化方案，在不增加内存占用的情况下，将误判率降低约 50%，同时保持极低的性能开销。
问题背景：单比特 Bloom Filter 的 occupancy 困境
Bloom Filter 的核心是一个长度为 m 的比特数组，初始时全部置为 0。当插入元素时，通过 k 个哈希函数计算 k 个位置，并将这些位置设为 1。查询时，若所有 k 个位置均为 1，则返回「可能存在」；若任意一位为 0，则返回「一定不存在」。这个机制保证了零假阴性（永远不会漏掉已插入的元素），但会产生假阳性 —— 即未插入的元素恰好被误判为存在。
误判率的数学表达式为 (1 - e^(-kn/m))^k，其中 n 为已插入元素数量。当 n 接近 m 时，大量比特被置为 1，查询命中的概率随之上升。以 Floe 数据库的实践为例：使用 k=1 的单比特实现、m=2M（256KB）、n=256K 元素时，理论误判率高达 11.5%。这意味着每 10 次查询中约有 1 次会返回错误的「可能存在」结果，导致下游需要额外解压和处理本应跳过的数据块。
在 Floe 的存储引擎中，Bloom Filter 被用于两个关键场景：一是列存存储引擎的预过滤 —— 在解压列数据前快速排除必然不匹配的行；二是哈希连接探测阶段的过滤 —— 在查询哈希表前判断键值是否可能存在于构建侧。当误判率过高时，过滤器非但无法节省 I/O 和计算资源，反而会因为大量无效的「可能存在」判断而导致额外的解压和探测开销。
工程挑战：固定大小与并发写入的约束
Floe 选择使用固定 256KB 大小的 Bloom Filter，这一设计决策背后有明确的工程考量。固定大小意味着无需动态内存分配，编译器可以进行激进的优化，内联代码路径可以做到极致的性能优化。同时，固定大小使得过滤器可以完全驻留在 L2/L3 缓存中，避免昂贵的缓存未命中。在并发写入场景下，固定大小的数组也更容易实现无锁（lock-free）的原子操作，保证多线程并发插入时的正确性和性能。
然而，固定大小带来的副作用是 occupancy（填充率）随元素增加而持续上升。当填充率超过一定阈值后，误判率会迅速攀升到不可接受的范围。传统的解决思路包括增加过滤器大小（但会占用更多缓存）、增加哈希函数数量（但会增加计算开销），或者使用更复杂的数据结构如 Cuckoo Filter 或 XOR Filter—— 但这些替代方案往往需要动态扩容或更复杂的寻址机制，与固定大小的设计目标相冲突。
双比特编码的核心理念
双比特编码的核心思想是在同一个 32 位整型变量中存储两位信息，而非像传统实现那样每个比特独立使用。具体实现中，将一个 uint32 视为 32 个独立的 1 比特位置；现在将其重新解释为 16 个双比特单元（cell），每个单元占用相邻的两位。通过巧妙的哈希计算，来自同一个原始哈希值的两位可以被映射到同一个 uint32 的不同比特位置，从而在一次内存访问中完成两位的设置和检查。
这种设计带来了显著的优势。首先是内存访问次数不变 —— 无论是单比特还是双比特实现，都只需要一次内存读取或写入操作。其次是原子操作开销相同 —— 使用原子 OR 指令可以一次性设置两位，无需额外的同步原语。第三是缓存行为一致 —— 由于操作的是同一个缓存行（cache line），现代处理器的预取机制可以有效工作。最后是代码复杂度可控 —— 新增的仅是位运算逻辑，不引入新的数据结构或算法复杂度。
具体的哈希与位运算实现
在 Floe 的实现中，原始哈希值被拆分为多个字段用于不同的用途。假设使用 32 位哈希值，较低的 16 位用于选择数组中的元素索引（即 uint32 数组的下标），接下来的 5 位用于计算第一个比特在 32 位整数中的位置，最后的 5 位用于计算第二个比特的位置。这样 32 位哈希值被充分利用，只剩余 6 位未使用。
代码实现中定义了三个关键函数。uint32Idx 函数通过将哈希值右移 16 位并与掩码进行按位与操作，得到数组索引。bitLoc1 函数通过将哈希值右移 16 位后再右移 5 位（即总共右移 21 位），并与 5 位掩码进行按位与，得到第一个比特的位置范围。bitLoc2 函数则通过将哈希值右移 21 位并与掩码进行按位与，得到第二个比特的位置。插入操作 put 计算出索引和掩码后，使用原子 OR 操作一次性设置两位；查询操作 contains 同样计算索引和掩码，然后检查两位是否都被设置。
这种实现的巧妙之处在于，两个比特位置都来自同一个哈希值的不同字段，而非使用两个独立的哈希函数。这意味着两个比特位置之间存在一定的相关性 —— 它们必然落在同一个 uint32 元素内，且位置相隔至少 32（因为 5 位编码范围是 0-31）。这种相关性在理论上会略微增加碰撞概率，但换取的是单次内存访问和原子操作的优势，实际性能收益远大于理论损失。
性能实测数据与分析
Floe 团队在相同硬件环境下对单比特和双比特实现进行了基准测试。插入操作（put）的性能从每操作 9.12 周期增加到 9.70 周期，开销增加约 6%。查询操作（contains）的性能从每操作 1.97 周期增加到 3.16 周期，百分比增加看似达到 60%，但绝对值仅增加了 1.2 个 CPU 周期。需要注意的是，3.16 周期仍然远小于一次函数调用的开销，甚至小于一次分支预测失败的成本 —— 这意味着在绝大多数应用场景下，额外的性能开销可以忽略不计。
关键的准确性指标取得了显著提升。误判率从单比特实现的 11.68% 下降到双比特实现的 5.69%，降幅接近 51%。以实际场景为例，在一次扫描 1TB 数据的查询中，这意味着可以避免解压约 60GB 的额外数据。考虑到解压操作的 CPU 密集型特性，这节省的时间远超过查询操作增加的纳秒级延迟。
为什么是 2 比特而不是 3 或 4 比特
一个自然的问题是：既然 2 比特能够降低误判率，为什么不使用更多的比特（比如 3 比特或 4 比特）？答案在于工程实践中的边际收益递减。使用在线的 Bloom Filter 计算器进行参数化分析可以发现：当使用 1 比特时，在误判率 5% 的约束下约能容纳 10 万个元素；使用 2 比特时，容量提升至约 25.3 万个元素，增幅达 2.5 倍；但继续增加到 3 比特时，容量仅提升至约 30.6 万个元素，增幅只有 20%；而 4 比特更是只增加到 32 万个元素，增幅不足 5%。
从内存效率的角度看，2 比特恰好位于单次内存访问的边界上。使用 32 位变量时，1 比特方案可以使用 32 个独立位置，2 比特方案可以使用 16 个双比特单元，3 比特方案则需要额外的位运算来处理跨字边界的情况，不再具备单次访问的优势。因此，2 比特是在工程实现复杂度和性能收益之间取得的最佳平衡点。
与其他过滤器的对比思考
尽管 Cuckoo Filter 和 XOR Filter 在理论上能够提供更低的误判率或更高的空间效率，但它们并不适合 Floe 的具体场景。Cuckoo Filter 需要动态扩容机制来支持元素删除和重新插入，这与固定大小的设计目标相悖。XOR Filter 虽然空间效率更高，但其构建过程需要预先知道全部元素集合，且不支持动态插入 —— 这对于流式数据处理和实时构建场景是一个重大限制。
Floe 的设计目标明确：固定大小（256KB）、无锁并发写入、可预测的缓存行为。双比特编码的 Bloom Filter 完美满足了这三个约束，同时在准确性上提供了约 2 倍的提升。对于追求极致性能的数据库引擎而言，这种「在既定约束下优化」的设计思路往往比「引入更复杂的数据结构」更为务实。
工程落地的监控与调优参数
对于希望在自身系统中实现类似优化的团队，以下参数值得关注。数组大小建议配置为 2 的幂次方（方便使用掩码替代取模运算），Floe 使用 2M（约 209 万）比特对应 256KB 内存。哈希函数数量在固定大小场景下 k=1 是最优选择 —— 这看似反直觉，但实际上当 m/n（比特与元素之比）较小时，额外的哈希函数带来的碰撞检测收益被计算开销抵消。掩码位宽应与 uint32 的位数匹配，5 位掩码对应值 31 用于提取比特位置。最后，原子操作应使用 __sync_fetch_and_or 或 C++11 的 std::atomic<uint32_t> 来保证多线程并发写入的正确性。
监控层面建议跟踪两个核心指标：一是过滤器填充率（已设置位数与总位数之比），当超过 70% 时应考虑扩容或重建；二是实际观测到的误判率，可通过对比过滤器判断结果与底层存储的确认结果来统计。当误判率超过预设阈值（如 10%）时，应触发告警以便运维人员及时处理。
结论
双比特编码为 Bloom Filter 提供了一条在固定内存约束下显著降低误判率的工程路径。通过精心设计的哈希值拆分策略和位运算逻辑，实现在单次内存访问中完成两位信息的存储与查询，将误判率从 11.68% 降至 5.69%，同时仅增加约 1.2 周期的查询延迟。这种「以微小的性能代价换取大幅准确性提升」的优化思路，在高性能数据库引擎的开发中具有广泛的参考价值。
资料来源：本文技术细节主要参考 Floe 数据库工程团队在 2026 年 2 月发布的技术博客《Two Bits Are Better Than One: making bloom filters 2x more accurate》（https://floedb.ai/blog/two-bits-are-better-than-one-making-bloom-filters-2x-more-accurate）。