bitmap filter在sql server中仅在并行hash join或merge join中启用，需小表先构建位图、大表扫描时用位图快速过滤不匹配行，且要求等值连接、无函数包装、统计信息准确；串行或nested loops下通常不出现。
Bitmap Filter在SQL Server中实际起效的条件是什么？
Bitmap Filter不是随时都出现的“万能加速器”，它只在特定物理连接类型和并行环境下被优化器启用。关键点有三个：
- 必须是
Hash Join或Merge Join，且处于并行执行计划中（串行Hash Join理论上也可能用，但执行计划里通常不显示该运算符） - 小表（通常是右表）需先完成构建位图的过程，位图基于其输出的关联列值（如
t1.ProductID）生成 - 大表（左表）在后续扫描时，会用这个位图快速跳过大量不匹配的行——不是逐行比对，而是查位数组对应位置是否为 1
如果你在执行计划里没看到 Bitmap 运算符，大概率是因为：连接方式是 Nested Loops、查询强制串行（MAXDOP 1）、或两表数据分布导致优化器放弃了哈希路径。
为什么Bitmap Filter对20万+行过滤特别有效？
核心在于它把“集合成员判断”从 O(n) 降到了 O(1)，而且几乎零内存拷贝：
- 位图本身极小：比如用 1MB 位数组就能编码约 800 万个不同整数值（8 bits × 1024×1024）
- 判断过程无哈希计算开销：只需取待查值做固定哈希（SQL Server 内部预设多个函数），定位到 bit array 的几个位置，全为 1 才认为可能命中
- 不匹配行直接被
Filter运算符丢弃，不进入后续 Join 的 probe 阶段，I/O 和 CPU 都省了
举个典型场景：SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.status = 'active'。如果 t1 是活跃子集很小的驱动表，优化器很可能在 t2 扫描前就生成一个 bitmap，让 t2 跳过 95% 以上无关记录。
Bitmap Filter和Bloom Filter索引是同一回事吗？
不是，这是最容易混淆的一点：
- SQL Server 的
Bitmap是查询执行期动态生成的临时结构，生命周期仅限单次查询，不持久、不可复用、不依赖建索引 - 它和 StarRocks / Doris 中的
BLOOMFILTER或BITMAP索引完全不同：后者是预建在存储层的物理索引，需要显式CREATE INDEX，用于加速WHERE条件或IN子句，与 JOIN 无直接关系
SQL Server 至今（2026 年）仍不支持用户创建位图索引。你看到的 Bitmap 运算符，完全是优化器在运行时根据统计信息和代价模型“悄悄做的决定”，无法手动开关，也无法通过 hint 强制启用。
哪些操作会意外禁用Bitmap Filter？
看似无关的写法，可能让优化器绕过 bitmap 路径：
- 在 JOIN 条件中使用函数或表达式，例如
ON UPPER(t1.code) = t2.code，破坏了等值匹配前提 - 使用
OPTION (RECOMPILE)时若参数嗅探失败，可能导致统计偏差，使优化器误判小表大小而放弃 bitmap - 表提示强制指定连接类型，如
INNER LOOP JOIN，直接排除了 hash 路径 - 查询中含
TOP、OFFSET/FETCH或窗口函数，有时会改变优化器对行数的预估逻辑，间接抑制 bitmap 生成
真正可控的干预手段只有两个：确保连接列为干净的等值字段 + 让统计信息保持新鲜（UPDATE STATISTICS）。其余都是在和优化器博弈，胜率不高。
