Vertica JOIN中使用OR导致查询性能急剧下降？

这个问题我之前在Vertica项目里踩过一模一样的坑，当时改完OR条件后查询直接跑了十几分钟，原来的单条件JOIN只需要几秒。我翻了Vertica的执行计划和官方文档，终于搞清楚了背后的原因：

先看正常单条件JOIN的高效逻辑 #

你的第一个查询：

select count(distinct tab1.id) from tab1 join tab2 on tab1.email = tab2.email_a;

Vertica作为列存数据库，对等值JOIN有非常成熟的优化：

• 它会优先选择哈希连接（Hash Join）：把较小的表（比如tab2）构建成哈希表，然后遍历较大的表（tab1）去匹配哈希表中的email_a，这个过程的时间复杂度是O(n+m)，非常高效。
• 如果两个表的email列已经通过投影（Projection）预排序，还会用合并连接（Merge Join），同样是线性时间复杂度。
• 同时，count(distinct tab1.id)可以在连接过程中提前去重，或者利用列存的压缩特性减少数据扫描量。

带OR的JOIN是怎么拖垮性能的？ #

当你改成带OR的条件后：

select count(distinct tab1.id) from tab1 join tab2 on tab1.email = tab2.email_a or tab1.email = tab2.email_b;

Vertica没办法再用上面的高效连接算法，主要原因有这几点：

1. 被迫使用低效的嵌套循环连接 #

哈希连接和合并连接都依赖单一等值条件，OR条件相当于把两个等值条件合并成一个“或”逻辑，这打破了高效连接的前提。Vertica只能退化为嵌套循环连接（Nested Loop Join）：

• 遍历tab1的每一行，然后在tab2中扫描所有满足email_a = tab1.email或者email_b = tab1.email的行。
• 如果tab2数据量很大，这个过程就是O(n*m)的时间复杂度，数据量上去后性能直接崩盘。

2. 中间结果集急剧膨胀 #

OR条件会导致tab1的一行可能匹配tab2的多行：比如同一个tab1.email既匹配tab2的某行email_a，又匹配另一行的email_b，甚至同一行的email_a和email_b都匹配。

• 这会让连接后的中间结果集比单条件JOIN大好几倍甚至几十倍，后续的count(distinct)需要处理大量重复的tab1.id，消耗更多内存和IO资源。

3. 无法利用投影或索引优化 #

Vertica的投影（Projection）是为等值查询和排序优化的，OR条件下，数据库没办法利用基于email_a或email_b的预排序投影，也没办法用索引快速定位匹配行，只能对tab2做全表扫描，而且每一行都要判断两个条件是否满足。

4. 执行计划的额外开销 #

你可以用EXPLAIN命令对比两个查询的执行计划，会发现带OR的查询里：

• 没有了Hash Join的步骤，取而代之的是Nested Loop或者笛卡尔积过滤。
• count(distinct)的步骤被推迟到了中间结果集生成之后，需要处理远大于原查询的数据量。

为什么拆成两个JOIN会高效？ #

你提到的用两个JOIN改写（比如用UNION ALL）：

select count(distinct id) from (
    select tab1.id from tab1 join tab2 on tab1.email = tab2.email_a
    union all
    select tab1.id from tab1 join tab2 on tab1.email = tab2.email_b
) t;

这种写法把OR拆成了两个独立的等值JOIN，每个JOIN都能用上Hash Join或Merge Join，而且Vertica可以并行处理这两个子查询。最后用UNION ALL合并结果再去重，中间结果集的膨胀程度远低于OR条件的JOIN，性能自然就上来了。

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