SEMI JOIN是数据库优化器将EXISTS子查询自动重写为的物理执行算子，只保留左表存在右表匹配的行；它不可手写，需满足等值关联、索引完备、无聚合/排序/去重等条件才能触发。
SEMI JOIN 是什么，为什么它能替代 EXISTS
大多数数据库（如 PostgreSQL、SQL Server、Oracle）在执行 EXISTS 子查询时，底层优化器会自动将其重写为 SEMI JOIN —— 但这仅在语义等价且索引可用的前提下成立。SEMI JOIN 不生成右表的列，只保留左表中“在右表存在匹配”的行，和 EXISTS 的行为完全一致。手动改写成显式 SEMI JOIN（比如用 INNER JOIN ... ON ... WHERE ... 加去重）反而可能破坏语义或引入重复，所以**不建议手写 SEMI JOIN**；真正该做的是让优化器能识别并高效执行 EXISTS。
让 EXISTS 被优化为 SEMI JOIN 的关键条件
优化器是否启用 SEMI JOIN，取决于子查询结构是否“干净”。以下情况会阻止优化：
-
EXISTS子查询里包含GROUP BY、HAVING、聚合函数（如COUNT(*)），哪怕只是装饰性写法 - 子查询中对右表字段做了非等值关联（如
t2.status != 'archived'在ON或WHERE中混用） - 左表连接键未建索引，或右表被关联字段无索引（尤其
t2.user_id这类外键字段） - 子查询里用了
SELECT *或多余列（虽不影响语义，但某些旧版本优化器会误判为需要投影）
正确写法示例：
SELECT u.id, u.name
FROM users u
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
AND o.created_at > '2024-01-01'
);这里 SELECT 1、单等值条件、右表过滤下推，都是友好信号。
EXISTS vs IN vs JOIN：什么时候不该换
别一看到 EXISTS 就想“改成 JOIN 更快”——这是常见误区：
-
IN (subquery)遇到NULL值会整体返回空结果，而EXISTS不受右表NULL影响，语义不同 - 用
INNER JOIN替代EXISTS可能导致左表行重复（例如一个用户有多笔订单），必须加DISTINCT或GROUP BY，反而增加开销 - 某些场景下（如右表极小、左表极大且无合适索引），
EXISTS的“找到即停”特性比 JOIN 的全量哈希/嵌套循环更省资源
简单判断：如果原逻辑是“查有没有”，就用 EXISTS；如果要“取匹配数据”，才考虑 JOIN。
验证是否真走 SEMI JOIN 执行路径
不能只看 SQL 写法，得看执行计划：
- PostgreSQL：运行
EXPLAIN (ANALYZE, VERBOSE)，关注子计划是否出现Hash Semi Join或Nested Loop Semi Join - SQL Server：看执行计划 XML 中是否有
<relop nodeid="X" physicalop="Nested Loops" logicalop="Inner Join"></relop>并带SemiJoin属性 - MySQL 8.0+：
EXPLAIN FORMAT=TREE里若显示> semijoin表示已启用
如果计划里仍是 Subquery 或 DEPENDENT SUBQUERY，说明优化器放弃重写——这时候优先检查索引和子查询结构，而不是强行改写语法。
最常被忽略的一点：SEMI JOIN 的效率高度依赖右表驱动字段的索引选择性。哪怕语法完美，若 orders.user_id 上只有低基数索引（比如只有 status 单列索引），优化器也可能拒绝 SEMI JOIN 路径。
