EXISTS通常比IN快，因其采用短路机制，找到首行即停止；而IN需先物化整个子查询结果集再匹配，尤其在结果集大、无索引时性能急剧下降。
EXISTS 子查询为什么比 IN 快？
核心原因不是语法高级，而是执行机制不同：EXISTS 只关心“有没有一行满足”，找到第一条就短路退出；而 IN 配合子查询时，数据库通常先物化整个子查询结果（生成临时表），再做全量匹配。尤其当子查询返回上万行、外层表又很大时，性能差距会指数级放大。
但这个优势有个前提：子查询的 WHERE 条件里必须能用上索引。如果内层 SELECT 1 FROM t2 WHERE t2.id = t1.id 中的 t2.id 没索引，EXISTS 也会全表扫描，和 IN 没区别。
- 检查执行计划，确认
EXISTS子查询是否走了索引（type显示ref或range，key列非NULL） - 避免在子查询中对字段做函数操作，比如
WHERE YEAR(create_time) = 2025会让索引失效 -
EXISTS子查询里SELECT *和SELECT 1效果一样，但写SELECT 1更明确，部分旧版 MySQL 会少解析点字段
多层 EXISTS 嵌套时怎么避免性能雪崩？
三层及以上 EXISTS 嵌套（比如 A EXISTS (B EXISTS (C))）容易触发“相关子查询反复执行”问题：外层每扫一行，中间层就重跑一次，中间层每跑一次，内层又重跑一次。实际执行次数可能是 O(n×m×k)，而不是看起来的“三层逻辑”。
- 优先把最内层子查询独立出来，用
JOIN或CTE预计算——例如把EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')提前算成用户维度的标志位，存在临时表或物化视图里 - 检查是否真需要嵌套：很多业务场景其实可以用单层
EXISTS+ 多条件AND实现，比如EXISTS (SELECT 1 FROM t2 WHERE t2.a = t1.a AND t2.b = t1.b AND t2.c > 100) - MySQL 8.0+ 支持
LATERAL关键字，可让子查询“按需关联”，比传统嵌套更可控，但注意兼容性
NOT EXISTS 的坑：空值和 NULL 安全性
NOT EXISTS 看似是 EXISTS 的反向，但遇到 NULL 时行为很微妙。比如 WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id) 能正确找出所有 t1 中无对应 t2 记录的行；但若写成 WHERE t1.id NOT IN (SELECT id FROM t2)，只要 t2.id 里有一个 NULL，整个条件就恒为 UNKNOWN，结果集直接为空。
-
NOT EXISTS不受子查询中NULL影响，它是基于“是否存在匹配行”做布尔判断，天然安全 - 但
NOT EXISTS无法利用反向索引优化，某些场景下比LEFT JOIN ... IS NULL慢，特别是子查询结果集很大时 - 如果子查询本身可能返回空（比如
SELECT 1 FROM t2 WHERE ... LIMIT 0），NOT EXISTS仍会返回TRUE，这点要和业务逻辑对齐
什么时候该放弃 EXISTS，改用 JOIN？
当你要的不只是“是否存在”，而是“存在多少个”“存在哪些具体字段”“需要聚合统计”时，硬套 EXISTS 反而绕路。比如查“每个部门是否有至少一名薪资超 2w 的员工”，用 EXISTS 可以；但查“每个部门超 2w 员工数”，就必须用 LEFT JOIN 或子查询配合 COUNT。
- 需要去重计数、求和、取最大值等聚合结果时，
EXISTS无法直接提供，强行用标量子查询会触发多次执行 - 外层查询本身就要关联其他表，再叠
EXISTS容易让优化器放弃使用索引合并，此时统一改用JOIN+GROUP BY+HAVING更稳定 - 某些 OLAP 场景下，
EXISTS在分区表上可能无法下推谓词，而JOIN可以更好利用分区裁剪
复杂点往往不在语法，而在你是否清楚：这一层嵌套，到底是在做存在性断言，还是在悄悄承担数据聚合或关联职责。没想清这点，优化就只是调参。
