用 EXISTS 替代 IN 防止 NULL 引发逻辑错误和计划退化

IN子句有个著名的陷阱：当子查询返回的结果里包含NULL值时，即使存在匹配项，整个行也可能被意外过滤掉。这还只是逻辑层面的问题，更隐蔽的是性能风险。在某些数据库版本中，如果IN (subquery)里的子查询包含NULL或者关联字段缺少索引，优化器很可能“打退堂鼓”，放弃高效的半连接计划，转而采用嵌套循环或临时表扫描这种更慢的方式。

这时候，EXISTS就成了更稳妥的选择。它的语义非常清晰——“只关心是否存在匹配行”，不仅天然规避了NULL值带来的逻辑陷阱，也更能稳定地触发优化器的半连接优化机制。来看个例子：

SELECT * FROM orders o
WHERE EXISTS (
  SELECT 1 FROM customers c
  WHERE c.id = o.customer_id AND c.status = 'active'
);

• 逻辑安全：EXISTS子查询的结果是真是假，完全不受其中NULL值的影响。
• 索引是关键：务必确保子查询中的关联字段（比如这里的c.id）上有索引。没有索引，优化器选择哈希半连接的意愿会大大降低。
• 保持子查询简洁：记住，优化器只关心“是否存在”，所以子查询里用SELECT 1就足够了。使用SELECT *或包含复杂的表达式，不仅多余，还可能干扰优化器的成本估算，导致它选错执行计划。

避免在 IN 右侧用子查询，尤其带聚合或 DISTINCT

像WHERE id IN (SELECT DISTINCT user_id FROM events)这样的写法，看起来挺简洁，对吧？但问题就出在DISTINCT上。它会让优化器难以预估子查询结果集的大小，常常导致其放弃半连接，转而采用物化（Materialize）加哈希查找的方案，内存开销大，速度也慢。

更友好的等价写法是这样的：

SELECT * FROM users u
WHERE EXISTS (
  SELECT 1 FROM events e
  WHERE e.user_id = u.id
);

• 让连接本身去重：直接去掉DISTINCT。半连接操作本身就有去重的特性，无需画蛇添足。
• 复杂聚合提前处理：如果业务逻辑确实需要先做聚合（例如查找“近7天登录过的用户”），一个有效的策略是先将子查询物化为CTE（公共表表达式）或临时表，并在这个结果集上建立索引。PostgreSQL等数据库支持类似的操作。
• 注意数据库特性：以MySQL 8.0+为例，它确实有针对IN (subquery)的半连接优化标志，但默认开启的这个优化，一旦遇到子查询里包含GROUP BY或窗口函数，就会自动禁用。了解这些细节才能避免踩坑。

检查执行计划，确认是否真用了 Hash Semi Join

查询改写完了，事情只做了一半。必须验货，确认优化器是否真的如我们所愿，选择了哈希半连接。

在PostgreSQL中，使用EXPLAIN (ANALYZE, BUFFERS)查看执行计划，寻找输出中的Hash Semi Join节点。在Spark SQL中，则要关注EXPLAIN输出里是否有SemiJoin或BuildLeft这类标识。

• 计划不如预期怎么办？：如果执行计划里出现的是Nested Loop（嵌套循环）或Materialize（物化），那就说明优化器没走半连接。这时候需要回头检查：子查询的关联条件字段是否有索引？子查询是否因为引用了外部查询的列而导致谓词无法下推？
• 数据库差异：不同数据库有不同脾气。比如ClickHouse，它会默认将IN子查询转为JOIN，但如果右表数据量过大（例如超过1万行），可能会自动切换为GLOBAL IN，引发网络广播，此时手动改写为JOIN并结合PREWHERE过滤往往是更好的选择。
• 一个常见的优化死角：父查询的过滤条件没有“下推”到子查询中。例如WHERE status = 'paid' AND id IN (SELECT id FROM refunds)，更好的写法是将过滤条件融入EXISTS子句：WHERE EXISTS (SELECT 1 FROM refunds r WHERE r.id = t.id AND r.reason IS NOT NULL)，让过滤尽早发生，减少需要处理的数据量。

最后必须强调，半连接优化并非银弹。它高度依赖准确的表统计信息和清晰、干净的关联路径。一旦子查询中混入了OR条件、对字段使用了函数，或者涉及跨库查询，优化器很可能就直接放弃治疗了。

遇到这种复杂情况，与其在单条复杂查询上硬磕，不如考虑分两步走：先用一个简单的查询取出有限的ID列表（可以用LIMIT控制大小），然后再用IN (val1, val2, ...)进行主查询。化繁为简，有时候反而是最快的路径。