exists语义天然匹配semi-join，只保留左表存在右表匹配的行且不取值、不计数、不关心重复；需满足select 1、等值关联、索引完备、无聚合/排序等条件才能触发，否则退化为dependent subquery。
EXISTS 语义天然匹配 Semi-Join 行为
EXISTS 的作用就是判断“左表某行在右表是否存在至少一条匹配”，不取值、不计数、不关心重复——这和 Semi-Join 的定义完全一致：只保留左表中能与右表建立等值关联的行，且每行最多返回一次。优化器不需要额外逻辑就能确认语义等价，所以只要条件满足，它就倾向走这条路径。
不转换的常见硬性原因
即使语义对得上，优化器也可能放弃 Semi-Join，直接退化为 DEPENDENT SUBQUERY（每行执行一次子查询）。关键拦路虎包括：
-
SELECT *或SELECT customer_id—— 必须写SELECT 1，否则优化器可能误判需回表取字段 - 子查询里用了
COUNT(*)、GROUP BY、ORDER BY或UNION—— 这些强制物化，Semi-Join 被禁用 - 关联字段没索引，或类型不一致导致隐式转换（比如
INT对VARCHAR）—— 索引失效，优化器算出走 Nested Loop 更便宜 -
optimizer_switch中semijoin=off被手动关闭（线上环境偶有发生）
怎么确认真的走了 Semi-Join？
别信经验，看执行计划。MySQL 下运行：
EXPLAIN FORMAT=TREE SELECT * FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);
如果输出里出现 Semi-join (firstmatch) 或 Semi-join (duplicateweedout)，说明成功；若看到 MATERIALIZE、Using temporary 或 type=ALL + Extra=Using where; Using join buffer，那就是没走成。
特别注意 rows_examined_per_scan：Semi-Join 下这个值应接近 1（找到第一个就停）；如果等于 orders 总行数，说明短路机制完全没生效。
IN 和 EXISTS 在 Semi-Join 上的实际差异正在消失
MySQL 8.0.16+ 开始，优化器对 IN 和 EXISTS 的处理策略已基本拉平。只要子查询结构干净（单 SELECT、无聚合、等值关联、索引完备），两者都可能触发 Semi-Join。真正卡住性能的，往往不是选 IN 还是 EXISTS，而是改写后没验证 NULL 行是否被意外过滤、没核对执行计划里是否真出现了 hash_join 或 semi_join 节点——这些细节一漏，优化就变成劣化。
