EXISTS子查询未走半连接的三个硬性条件是：存在关联条件、无聚合函数、SELECT列为常量；任一不满足即退化为嵌套循环或物化执行。
EXISTS子查询没走半连接的三个硬性条件不满足
写了EXISTS不代表一定触发半连接，优化器会直接跳过转换，退化为嵌套循环。最常见原因是子查询里缺关联条件、含聚合或SELECT *——这些都会让优化器放弃半连接路径。
-
EXISTS (SELECT 1 FROM t2 WHERE status = 'active')：没写t2.id = t1.id这类关联谓词，优化器视为独立子查询，无法推导存在性语义 -
EXISTS (SELECT COUNT(*) FROM t2 WHERE t2.a = t1.b)：哪怕只加COUNT(*)，就破坏了“只判存在”的语义，降级为物化执行 -
EXISTS (SELECT t2.id FROM t2 WHERE t2.a = t1.b)：SELECT列不是常量（如1），某些版本（如 MySQL 5.7）会误判需回表取值，不敢展开
IN子查询在MySQL 8.0+仍显示"DEPENDENT SUBQUERY"的典型原因
即使升级到 MySQL 8.0.22+，EXPLAIN FORMAT=TREE里仍看不到
- 子查询含
LIMIT或OFFSET：例如WHERE id IN (SELECT user_id FROM logs ORDER BY ts DESC LIMIT 1)，语义上不可并行展开，强制走相关子查询 - 子查询有
GROUP BY或HAVING：哪怕只是GROUP BY user_id，优化器也无法保证“一行匹配即终止”，短路逻辑失效 - 统计信息过期：
ANALYZE TABLE没跑过，优化器估算右表行数远超阈值，判定哈希半连接内存开销更大，宁可选嵌套循环
PostgreSQL中EXPLAIN没显示"Hash Semi Join"但实际走了半连接？
别只盯着执行计划文字。PostgreSQL 14+ 的EXPLAIN (ANALYZE, BUFFERS)里没出现Hash Semi Join，不代表没走——它可能被合并进Nested Loop节点，或因子查询带LIMIT退化为Subquery Scan。
- 关键看
Rows Removed by Filter是否接近 0：如果子查询每次只查几行就返回，说明短路生效，本质仍是半连接行为 - 检查
Buffers读取量：若shared hit占比高且read极少，说明右表数据被高效复用，非重复扫描 - 用
pg_stat_statements对比total_time和calls：若calls远小于主表行数，证明子查询没被重复执行
SQL Server执行计划里找不到"SemiJoin"字样怎么办？
图形界面通常不标SemiJoin，得从节点行为反推。重点盯Nested Loops或Hash Match的Predicate字段，以及右表是否被整体加载。
- 打开
SET STATISTICS XML ON，查sys.dm_exec_query_plan输出的XML，搜索SemiJoin或Left Semi Join - 图形计划中，若
Hash Match的Logical Operation是Inner Join，但Output List只含左表字段，且Estimated Number of Rows与左表一致，基本就是半连接 - 右表扫描类型是
Table Scan而非Index Seek，且Actual Number of Rows Read远大于Actual Number of Rows，说明优化器做了全量加载+哈希匹配，而非逐行探查
真正卡住的不是“为什么没展开”，而是你默认它该展开——而数据库只在成本估算明确更低时才动手。一旦子查询字段没索引、统计信息不准、或语义稍有歧义，它就退回保守策略。验证是否真慢，得看Rows Removed by Filter和实际执行耗时，而不是纠结执行计划里有没有那个词。
