LevelDB布隆过滤器的序列号处理逻辑及键匹配一致性疑问

这个问题问得特别好，刚好抓住了LevelDB布隆过滤器设计里一个很容易被误解的细节！我当初看源码的时候也卡在这里过，现在给你拆解清楚：

1. 先明确两个关键Key的结构 #

• Internal Key（内部键）：LevelDB存储的核心键格式，由三部分组成：[user key（用户自定义键）][sequence_number（序列号）][type（操作类型）]，其中序列号+类型占固定8字节（56位序列号用于版本控制，8位类型标记是put还是delete）。
• Lookup Key（查询键）：查询时构造的键，用目标user key加上全局最大序列号kMaxSequenceNumber和查找类型kValueTypeForSeek生成，目的是在有序的SSTable中定位到该user key的最新版本。

2. 布隆过滤器只关注user key，而非完整Internal Key #

当SSTable写入数据时，FilterBlockBuilder::AddKey()接收的确实是完整的Internal Key，但在最终生成布隆过滤器的GenerateFilter()阶段，LevelDB会做一个关键处理：

从每个Internal Key中提取出纯user key部分，仅对user key进行哈希计算，然后设置布隆过滤器的对应位。

你可以查看FilterBlockBuilder::GenerateFilter()的源码，它会遍历所有待处理的Internal Key，剥离掉后面的序列号和操作类型，只保留user key传递给布隆过滤器策略类（比如默认的BloomFilterPolicy）来生成过滤规则。

3. 查询时的匹配逻辑 #

当调用KeyMayMatch()时，传入的是带最大序列号的Lookup Key，但LevelDB的处理逻辑和写入时一致：

• 先从Lookup Key中提取出纯user key（和写入时的user key完全一致）
• 用这个user key计算哈希值，再去布隆过滤器中检查对应位

换句话说，不管写入时用的是哪个序列号，只要user key相同，哈希结果就完全一致，布隆过滤器自然能返回正确的“可能存在”结果。

4. 为什么要这么设计？ #

核心目的是让布隆过滤器的作用更精准：我们用布隆过滤器是为了快速判断「某个user key是否可能存在于当前SSTable中」，而不关心它的具体版本（序列号）。如果把序列号也纳入哈希计算，同一个user key的不同版本会被当成不同的键，导致布隆过滤器无法正确识别该user key是否存在，完全失去了它的性能优化意义。

内容的提问来源于stack exchange，提问作者user13032855