EXISTS子查询短路本质是“找到即停”，执行引擎扫描到首条匹配行即返回TRUE，不物化结果集；依赖索引、相关性及连接算法，无ORDER BY/LIMIT/聚合时最有效。
EXISTS 子查询在 SQL 中确实会短路，但它的“短路”不是像编程语言中 && 那样逐行判断后立刻退出，而是由**执行引擎对子查询结果集做存在性检查时，一旦找到第一条匹配行就停止扫描**。
EXISTS 的短路本质是“找到即停”
数据库执行 EXISTS 时，并不求出整个子查询结果集，而是在底层执行类似“有没有至少一行满足条件”的逻辑。只要底层扫描（比如索引查找或表遍历）过程中发现第一行符合条件，就立即返回 TRUE，不再继续读取后续行。
- 即使子查询理论上能返回 100 万行，只要第 1 行就匹配，优化器通常只取这 1 行就结束子查询执行
- 这个行为依赖于执行计划是否支持 early-exit（例如使用索引范围扫描、或 Nested Loop 连接中的内表提前终止）
- 如果子查询涉及排序（
ORDER BY）、分页（LIMIT/OFFSET）或聚合（COUNT(*)），则无法短路——因为这些操作必须看到全部或部分完整结果
和 IN / JOIN 相比，短路更可控
IN 子查询若写成 col IN (SELECT col FROM t WHERE ...)，某些数据库（如老版本 MySQL）可能先物化整个子查询结果再做哈希查找，无法短路；而 EXISTS 天然避免物化，更适合“是否存在”的语义。
- LEFT JOIN + IS NULL 模拟“不存在”时，需扫描全部匹配行才能确认 null，一般不能短路
- EXISTS 对空结果集的处理也更直接：没找到任何行 → 返回 FALSE，无需等待扫描结束（只要确认扫完且无匹配）
影响短路效果的关键因素
是否真能短路，不只看语法，还取决于实际执行路径：
- 索引是否存在：有合适索引时，数据库可通过索引快速定位首行，大幅加速短路；全表扫描下仍需逐行检查，但找到即停
- 子查询是否相关（correlated）：相关子查询（引用外部表字段）每次外层行都会触发一次独立的短路判断；非相关子查询只执行一次
- 优化器选择的连接算法：例如使用 Nested Loop 时，内表子查询容易短路；Hash Join 或 Sort-Merge Join 则往往需要构建完整内表数据，失去短路优势
一个直观例子
假设执行：
SELECT name FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid');对每个用户 u，数据库去 orders 表查是否有任意一笔已支付订单。只要在 orders 中用 (user_id, status) 索引找到第一个 user_id=某值 AND status='paid' 的记录，就立刻判定 EXISTS 为 TRUE，跳过该用户的其余订单扫描。
