Oracle 19c 的 Bloom Filter 不支持跨实例分布式 JOIN，仅在单实例内 HASH JOIN（含并行）中生效；其启用需满足驱动表扫描高效、行数适中、探测表行数远多于驱动表、连接列类型一致等条件，并依赖准确统计信息与参数配置。
Oracle 19c 的 Bloom Filter 不用于“分布式 JOIN”，它只在单实例内的 HASH JOIN 场景下生效；所谓“分布式 JOIN”在 Oracle 中实际指并行执行（Parallel Execution），而 Bloom Filter 在并行场景下仅以 loose 模式（受 loose_bloom_filter_enabled 控制）参与，且效果受限。
为什么 Oracle 19c 没有真正意义上的分布式 JOIN Bloom Filter
Oracle 并不把数据分片到多个独立数据库实例做 JOIN（如 Doris 或 ClickHouse 那样），它的“分布”仅体现为并行进程间的数据分发（PX SEND / RECEIVE）。Bloom Filter 在这种架构下无法跨实例传播——每个并行服务器进程（PX Server）运行在同一个实例内，共享 SGA，但 Filter 本身不会被序列化传输到远端节点。因此：
-
V$SQL_JOIN_FILTER中的记录只反映本实例内某次并行子任务中是否创建/使用了 Filter，不是全局分布式效果 - 执行计划里出现
JOIN FILTER CREATE和JOIN FILTER USE，不代表数据被“推到远程库过滤”，只是本机多个 PX 进程之间通过 QC 协调传递位图 - 若 SQL 走的是
BROADCAST或SHUFFLE类型的并行分发，Bloom Filter 通常不会启用——因为探测表（probe side）已被重分布，Filter 失去下推价值
哪些 HASH JOIN 场景下 Bloom Filter 可能被启用（含并行）
必须同时满足以下条件，优化器才可能生成 Bloom Filter：
- 连接类型是
HASH JOIN（非NESTED LOOPS或MERGE JOIN），且驱动表（build side）走全表扫描或高效索引范围扫描 - 驱动表预估行数在几万到百万级（太小则 Filter 开销反超收益；太大则位数组膨胀，假阳性率失控）
- 探测表（probe side）预估扫描行数远大于驱动表（建议 ≥ 10 倍），且无有效索引支撑连接列过滤
- 连接列无隐式类型转换，例如
orders.o_custkey = customer.c_custkey两边都是NUMBER，而非一边是VARCHAR2 - 若开启并行，需确保
loose_bloom_filter_enabled = TRUE（默认），且并行度不高（DOP ≤ 8更易触发）
如何确认 Bloom Filter 在并行 HASH JOIN 中真实起效
不能只看执行计划里有没有 Using join buffer (hash join with bloom filter)，必须查运行时视图：
- 执行 SQL 后立即查
V$SQL_JOIN_FILTER，过滤SQL_ID匹配当前语句，并检查FILTERED_ROWS是否显著小于UNFILTERED_ROWS（例如 5000 vs 800 万） - 若
FILTERED_ROWS = 0，常见原因是驱动表 WHERE 条件写在 JOIN 之后（如ON ... AND t1.status = 'A'写错位置），导致优化器误判驱动表大小 - 若同一 SQL 多次执行后
V$SQL_JOIN_FILTER无记录，说明该次执行根本没走 Bloom Filter 路径——可能是统计信息过期，或并行度动态降级为串行 - 注意：并行查询中一个 SQL 可能产生多条
V$SQL_JOIN_FILTER记录（每个 PX Server 一条），要汇总看总过滤量
容易被忽略的并行 + Bloom Filter 兼容性陷阱
即使参数开着、执行计划看着对，Bloom Filter 在并行场景下仍极易失效：
-
_bloom_filter_enabled = FALSE是全局禁用开关，比loose_bloom_filter_enabled更底层；某些 DBA 为压测临时关闭后忘记恢复，会导致所有 HASH JOIN（含并行）丢失 Filter - 并行时若驱动表用了
PARALLELhint，但探测表没加，可能导致数据分发不均，优化器放弃 Filter 构建 - 分区表上做局部索引扫描时，若分区裁剪（partition pruning）已非常高效，优化器可能认为无需再加 Bloom Filter
-
/*+ NO_BLOOM */这类 hint 会直接压制 Filter，但它不区分并行/串行——只要存在，就全禁
真正影响 Bloom Filter 是否落地的，从来不是“要不要开”，而是驱动表够不够“干净”：有没有准的统计信息、连不连得上索引、WHERE 条件写在哪一层。并行只是放大了这些前置条件的误差——一旦估算偏差超过阈值，Filter 就自动消失，连日志都不会留一行。
