exists子查询无需手写semi_join，数据库引擎会自动识别并选择半连接物理算子；其高效执行需满足四个条件：外层关联字段等值匹配、被关联字段有索引、子查询无group by/order by/limit/union/distinct/聚合函数、不涉及null逻辑陷阱。
EXISTS 子查询根本不需要“写 Semi Join”
SEMI_JOIN 不是 SQL 语法关键字，你不能在 WHERE 或 FROM 里手写 SEMI JOIN。MySQL、PostgreSQL、TiDB 等引擎会在满足条件时，**自动把 EXISTS（或合规的 IN）识别为半连接语义，并选择 Hash Semi Join、Nested Loop Semi Join 等物理算子执行**。强行加 SEMI_JOIN 关键字只会报错：syntax error at or near "SEMI"。
让优化器真正走 Semi Join 的四个硬性条件
即使写了 EXISTS，优化器也可能退化为嵌套循环全表扫描——常见于以下任一情况未满足：
-
EXISTS子查询中必须包含对外层表字段的等值关联，例如c.id = o.customer_id；漏写或写错（如写成c.id = o.id）会导致变成非相关子查询，直接全表扫 - 子查询内被关联的字段（如
orders.customer_id）必须有有效索引；没索引时执行计划会出现type=ALL+Using where; Using join buffer - 子查询中不能含
GROUP BY、ORDER BY、LIMIT、UNION、DISTINCT或聚合函数；这些结构会让优化器放弃 unnesting，转为物化临时表 - 子查询不能返回
NULL并参与逻辑判断——但EXISTS本身免疫此问题，IN则会因NULL导致整行静默过滤
EXISTS 比 IN 更可控的三个实操细节
同样是存在性检查，EXISTS 在语义和执行层面更贴近半连接本意：
- 子查询里固定写
SELECT 1，避免解析多余列、防止优化器误判为需要字段投影 - 过滤条件（如
o.status = 'paid'）必须放在子查询WHERE中，而不是主查询后追加AND——否则会先做连接再过滤，失去半连接提前终止的特性 - 当外层表小、子查询表大时（比如查 100 行用户是否下过单），
EXISTS天然倾向用外层驱动 + 索引探查，比IN先物化百万行再哈希匹配更省内存、更快终止
TiDB 和 MySQL 8.0+ 的 semi-join 优化陷阱
即便满足全部条件，执行计划仍可能不按预期走 Hash Semi Join：
- TiDB 默认用子查询构建哈希表，若子查询结果集远大于外层表（比如
EXISTS里查 1000 万订单），哈希建表开销巨大；此时需加/*+ SEMI_JOIN_REWRITE() */HINT 让优化器改用外层建哈希 - MySQL 8.0+ 的
optimizer_switch='semijoin=on'虽默认开启，但只要子查询里出现窗口函数、CTE 引用或跨库表，就会自动禁用 semi-join 优化，回退到物化 - 执行计划里看到
Hash Join或Merge Join，不代表就是Hash Semi Join——必须确认Extra列含Using where; Semi join或类似标识
真正决定性能的，从来不是“有没有 semi-join”，而是“优化器有没有信心用索引快速判定存在性”。索引缺失、关联写错、子查询膨胀，三者任一出现，EXISTS 就会从秒级退化为分钟级——别只盯着执行计划里的单词，先盯紧 EXPLAIN 输出的 type 和 key 列。
