semi join不是标准sql语法，不能手写；高效实现存在性检查的唯一可靠方式是用exists并满足四个条件：相关等值关联、关联字段均有索引、子查询无group by/limit/distinct/聚合、固定写select 1。
SEMI JOIN 不是可写的 SQL 语法，你不能直接写 SEMI JOIN；真正高效判断“是否存在”的唯一可靠方式，是用 EXISTS 并确保优化器能把它转成半连接执行计划。
为什么不能手写 SEMI JOIN
PostgreSQL、MySQL、SQL Server、TiDB 等主流引擎都不支持 SEMI JOIN 作为关键字出现在 FROM 或 WHERE 中。写 SELECT * FROM t1 SEMI JOIN t2 ON ... 会直接报错：syntax error at or near "SEMI"。所谓“SEMI JOIN 优化”，是优化器在满足条件时自动选择的物理算子（如 Hash Semi Join 或 Nested Loop Semi Join），不是你手动指定的语法。
- ClickHouse 和 BigQuery 是例外，但行为不一致：ClickHouse 的
SEMI LEFT JOIN实际把WHERE条件当成 JOIN 条件处理，无法下推过滤 - 即使在支持的引擎里，
SEMI JOIN也不接受子查询中带GROUP BY、ORDER BY或聚合函数 - 依赖显式语法会锁死迁移路径——换到 PostgreSQL 就全挂
怎样让 EXISTS 触发真正的半连接
不是写了 EXISTS 就一定走半连接。优化器是否启用，取决于四个硬性条件是否同时满足：
- 子查询必须是相关子查询，且关联条件为等值匹配（如
c.id = o.customer_id），漏写或写成c.id = o.id就退化为非相关子查询 - 被关联字段（如
customers.id）和主表关联字段（如orders.customer_id）都必须有索引；缺一个就可能触发type=ALL全表扫描 - 子查询中不能含
GROUP BY、LIMIT、DISTINCT、UNION、窗口函数或 CTE 引用——这些结构会让优化器放弃 unnesting，改走物化 - 子查询里固定写
SELECT 1，避免SELECT *或复杂表达式，否则可能干扰优化器对“存在性检查”的识别
EXISTS 比 IN 更稳的三个实操细节
IN 在语义和执行上都比 EXISTS 更容易翻车，尤其涉及 NULL 或数据倾斜时：
-
IN遇到子查询返回NULL，整行直接判为UNKNOWN被过滤；EXISTS完全无视NULL，只看是否有行返回 -
IN子查询若含DISTINCT或GROUP BY，优化器常放弃半连接，改用Materialize+ 哈希查找，内存开销陡增 - 过滤条件必须写在子查询内（如
WHERE c.status = 'active'），而不是主查询后追加AND；否则会先做连接再过滤，失去半连接“首次匹配即退出”的短路优势
如何验证是否真走了半连接
别猜，用 EXPLAIN 看执行计划：
- PostgreSQL：找
Hash Semi Join或Nested Loop Semi Join节点；若看到Subquery Scan on (actual rows=1)，说明已内联优化，效果等同半连接 - MySQL：开启
EXPLAIN FORMAT=TREE，出现Semi-join (duplicate removal)才算生效；若显示Materialize或Cache，说明没走半连接 - TiDB：注意
EXPLAIN的Extra列，含semi join字样才确认启用；若子查询结果集过大，可能因哈希建表开销大而回退，此时需加/*+ SEMI_JOIN_REWRITE() */HINT
最容易被忽略的是：子查询中漏掉索引、或误把过滤条件写在主查询 WHERE 里——这两处一出错，EXISTS 就彻底退化为嵌套循环，性能断崖下跌。
