SEMI_JOIN不是SQL标准语法，数据库引擎自动对IN或EXISTS子查询选择哈希半连接算法；应优先用EXISTS替代IN以避免NULL陷阱和计划退化，并确保关联字段有索引、子查询简洁无DISTINCT或复杂表达式。
SEMI_JOIN 不是可写的 SQL 语法，强行写会报错：syntax error at or near "SEMI"。你真正能控制的，是写出能让优化器自动选择哈希半连接（hash semi-join）执行计划的结构——核心就三点：用 EXISTS、确保索引存在、避免破坏优化器判断的写法。
为什么不能手写 SEMI_JOIN
所有主流数据库（PostgreSQL、MySQL 5.6+、TiDB、ClickHouse、Spark SQL）都不支持 SEMI_JOIN 作为关键字出现在 SQL 中。它只是优化器内部的执行策略代号，不是用户接口。你在 WHERE 里写 SEMI_JOIN，数据库直接拒绝解析。看到执行计划里出现 Semi Join 或 Hash Semi Join，说明优化器已成功识别并启用该算法，而不是你“调用”了它。
EXISTS 比 IN 更可靠触发半连接
常见错误现象：WHERE id IN (SELECT user_id FROM events) 在子查询返回 NULL 时逻辑异常（整行被意外过滤），且某些 MySQL/PostgreSQL 版本下容易退化为嵌套循环或物化临时表。
-
EXISTS语义明确：只判断是否存在匹配行，不受NULL干扰 - 优化器更倾向对
EXISTS启用半连接，尤其当子查询关联字段（如c.id = o.customer_id）上有索引时 - 子查询中必须写
SELECT 1，而非SELECT *或复杂表达式——多查字段无意义，还可能干扰计划
示例：SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'active');
哪些写法会让优化器放弃半连接
即使语义等价，以下结构也会让优化器绕过半连接，回退到低效路径：
-
IN右侧含DISTINCT、GROUP BY、HAVING或聚合函数（如WHERE id IN (SELECT DISTINCT user_id FROM events)） - 外层
WHERE中用OR连接子查询条件（如status = 'pending' OR id IN (SELECT ...)） - 子查询出现在
SELECT子句中（相关子查询），每行都执行一次，无法半连接 - 子查询含
UNION或窗口函数（MySQL 8.0+ 会自动禁用semijoin优化）
若必须先聚合（比如“近7天活跃用户”），应提前物化：用 CTE 或临时表，并在该结果上建索引（PostgreSQL 支持对物化 CTE 加 CREATE INDEX）。
驱动表大小影响哈希半连接效率
哈希半连接要求用**小表构建哈希表**。如果子查询结果集远大于外表（比如 EXISTS (SELECT 1 FROM huge_log_table ...)），而优化器仍坚持用它建哈希表，性能反而更差。
- TiDB 提供
SEMI_JOIN_REWRITE()HINT 强制交换驱动关系 - MySQL 可通过
/*+ NO_SEMIJOIN() */关闭半连接，改用物化；或加/*+ HASH_JOIN(t1, t2@sel_2) */强制哈希但需确认大小关系 - 务必用
EXPLAIN查看实际执行计划中的rows和Extra字段，验证是否真走了Semi Join
最容易被忽略的一点：索引缺失时，优化器根本不会考虑半连接——哪怕你写了最标准的 EXISTS，没索引就是白搭。
