SEMI JOIN并非标准SQL语法，而是优化器对EXISTS或IN子查询的物理执行策略；实际应使用EXISTS(SELECT 1...)等语义等价写法，配合索引与EXPLAIN验证执行计划。
SEMI JOIN不是标准SQL语法，但多数现代引擎都支持等价写法
SQL标准里没有 SEMI JOIN 关键字，它本质是优化器对 EXISTS 或 IN 子查询的物理执行策略。你不能直接写 SELECT * FROM t1 SEMI JOIN t2 ON ... —— 这在 PostgreSQL、SQLite、MySQL 里都会报错。真正能用的，是语义等价且被优化器识别为半连接的写法。
核心判断依据：只要子查询只关心“是否存在匹配行”，不取子表字段、不关心重复次数，优化器就大概率生成 SEMI JOIN 执行计划。
-
EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.ref_id)—— 最典型、最安全的 SEMI JOIN 触发写法 -
t1.id IN (SELECT t2.id FROM t2)—— 在 t2.id 无 NULL 时等价，但有 NULL 时语义不同（IN全为 UNKNOWN） -
LEFT JOIN ... WHERE t2.id IS NOT NULL是 ANTI JOIN 的常见误用，不是 SEMI JOIN；它可能多扫数据、无法短路
PostgreSQL 和 SQL Server 会自动把 EXISTS 转成 Hash/Loop Semi Join
以 PostgreSQL 为例，只要子查询满足“非关联列不参与输出 + 关联条件明确”，EXISTS 就大概率触发 Hash Semi Join 或 Nested Loop Semi Join。你可以用 EXPLAIN 验证：
EXPLAIN SELECT * FROM orders o WHERE EXISTS ( SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'active' );
你会看到执行计划里出现 Hash Semi Join 或 Subquery Scan on ... (actual rows=1) —— 后者说明已内联优化，效果等同 SEMI JOIN。
- 确保
customers.id和orders.customer_id都有索引，否则可能退化为 Nested Loop + 全表扫描 - 子查询中避免
SELECT *或复杂表达式，SELECT 1最轻量，也更易被优化器识别为存在性检查 - SQL Server 的
EXISTS同样默认走Semi Join，且支持FORCE ORDER提示控制驱动表顺序
ClickHouse 和 BigQuery 支持显式 SEMI JOIN 语法，但行为有差异
ClickHouse 是少数提供原生 SEMI JOIN 关键字的引擎，写法简洁但限制明确：
SELECT o.* FROM orders AS o SEMI LEFT JOIN customers AS c ON o.customer_id = c.id WHERE c.status = 'active';
注意：这里 SEMI LEFT JOIN 实际等价于 “保留左表中在右表有匹配的行”，和 EXISTS 完全一致；但它不支持 WHERE 条件下推到右表（如上例中 c.status = 'active' 会被当作 JOIN 条件处理，不是过滤后半连接）。
- BigQuery 不支持
SEMI JOIN关键字，但EXISTS同样被优化为高效半连接，且支持关联子查询中的窗口函数（其他引擎通常不支持） - ClickHouse 的
SEMI JOIN不能用USING，必须显式写ON；也不支持右表聚合或子查询嵌套 - 两者都不允许在
SEMI JOIN右侧引用左表字段做计算（比如ON c.id = o.customer_id + 1可能失败或性能极差）
别为了“用SEM I JOIN”而改写，优先保证语义正确和可读性
很多团队看到“SEMI JOIN 更快”就强行把 EXISTS 改成 JOIN + DISTINCT，结果反而变慢甚至逻辑错误。真实瓶颈往往不在连接类型，而在索引缺失、统计信息过期或子查询未参数化。
- 先用
EXPLAIN ANALYZE看实际执行计划，确认是不是真用了 Hash Semi Join；如果不是，优先加索引或更新统计信息（ANALYZE table） - 如果子查询含
LIMIT 1，某些引擎（如 MySQL 5.7）可能无法识别为 SEMI JOIN，应删掉 ——EXISTS本就隐含“找到一个就停” - 跨分片或跨库场景下，
EXISTS可能被下推执行，而显式SEMI JOIN（如 ClickHouse）要求两表在同一节点，否则报错
真正影响性能的，往往是右表是否能走索引查找、驱动表大小是否可控、以及连接键的选择性。语法糖只是表象，执行路径才是关键。
