exists子句触发半连接需同时满足三个前提：子查询含明确关联字段、select列表为常量（如select 1）、不含distinct/聚合/窗口函数；否则退化为dependent subquery。
EXISTS子句触发半连接的前提条件是什么
MySQL不会对所有EXISTS都做半连接转化，必须同时满足三个硬性条件：子查询里有明确的关联字段（比如WHERE o.user_id = u.id），SELECT列表只能是常量（推荐SELECT 1），且子查询不能含DISTINCT、聚合函数或窗口函数。漏掉任一条件，优化器就会退回到传统的相关子查询模型，表现为select_type=DEPENDENT SUBQUERY。
如何从EXPLAIN中确认是否走了半连接
执行EXPLAIN FORMAT=TREE是最直接的方式。重点看输出结构里有没有出现Semi-join字样——例如-> Semi-join (duplicate removal)或-> FirstMatch。如果没看到，再查EXPLAIN FORMAT=TRADITIONAL的Extra列：Using where; FirstMatch或Start temporary / End temporary也是半连接生效的信号。而Using join buffer (hash join)则说明走的是物化策略，不是半连接。
不同半连接策略的实际行为差异
MySQL把半连接拆成三种执行路径，选哪条取决于成本估算，但每种行为差别很大：
-
FirstMatch：对外表每行，在内表索引上找第一个匹配就停，适合内表小、匹配率低的场景 -
DuplicateWeedout：把外表行和内表匹配结果都写进临时表去重，内存压力大，10万级外表行可能直接OOM -
Materialization：先执行子查询并缓存结果，再对外表做哈希查找——这其实是IN的典型路径，EXISTS走这条路说明优化器没识别出短路语义
为什么EXISTS有时比IN还慢
表面看EXISTS天然短路，但实际性能取决于驱动逻辑是否可控：
- 外表（主查询）没索引、又没WHERE过滤，导致
rows_examined_per_scan暴增，EXISTS会重复执行子查询N次 - 子查询里的关联字段没索引，每次都是全表扫描，哪怕只找1条也扫完整张表
- MySQL版本低于8.0.16时，EXISTS默认不参与半连接优化，
optimizer_switch='semijoin=off'被意外关闭也会禁用该能力 - 写了
EXISTS (SELECT * FROM ...)而不是SELECT 1，某些版本会误判需回表取值，强制放弃半连接
真正影响性能的从来不是语法本身，而是外表扫描行数、内表索引覆盖度、以及优化器是否成功推导出半连接语义——这三个点漏掉任何一个，EXISTS就只是“看起来高效”。
