exists能短路而in不能，因exists只需找到首行即返回true，in必须先物化全部子查询结果再匹配；二者执行模型本质不同。
EXISTS 为什么能短路而 IN 不能
因为 EXISTS 的语义就是“是否存在”，数据库优化器在生成执行计划时，只要子查询命中第一行就立刻返回 TRUE，后续数据完全不扫描；而 IN 必须先把子查询完整执行一遍，把所有结果（比如 SELECT user_id FROM logs WHERE type = 'login' 返回 80 万行）物化成临时集合，再逐个比对——哪怕外层只查 10 行，也要先扛住这 80 万行的内存和哈希建表开销。
关键区别在于：EXISTS 是「按需触发 + 立即退出」，IN 是「先算完 + 再匹配」。这不是语法糖差异，是执行模型的根本不同。
EXISTS 必须写对关联条件，否则等于白写
常见翻车现场：WHERE EXISTS (SELECT 1 FROM orders WHERE status = 'paid') —— 这条语句没关联外层表，等价于“只要 orders 表里存在任意一条已支付订单，就返回主表所有行”，完全失去存在性判断意义。
正确写法必须带外层字段引用，例如：WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')。只有这样，优化器才能识别为相关子查询，进而启用半连接（Using semi-join）优化路径。
容易忽略的细节：
-
SELECT *或SELECT id在 EXISTS 子查询中会干扰优化器判断，应始终用SELECT 1 - 子查询里加
DISTINCT、COUNT(*)、ORDER BY会让优化器放弃半连接，降级为物化执行 - MySQL 5.6+ 默认开启
semijoin，但若optimizer_switch='semijoin=off'，EXISTS 也会退化为嵌套循环
什么时候 IN 其实更快？别迷信 EXISTS
EXISTS 并非银弹。当出现以下情况时，IN 可能更优：
- 子查询结果集极小（比如
SELECT id FROM roles WHERE type IN ('admin', 'moderator')只返回 2 行），IN 执行一次子查询即可，EXISTS 却要对外层每行都调一次 - 外层表极大（如日志表 500 万行），而子查询有强过滤且能走索引范围扫描（如
WHERE id BETWEEN 1000 AND 1010），此时 IN 的物化成本低，且外层可利用自身索引快速定位 - 子查询是静态值列表：
WHERE status IN ('active', 'pending', 'archived')，这类根本不会触发子查询，MySQL 直接做哈希查找
简单验证方法：对两条语句分别跑 EXPLAIN FORMAT=JSON，重点看 rows_examined_per_scan 和是否出现 Using join buffer —— 后者通常意味着性能风险。
NOT EXISTS 是唯一安全的否定写法
NOT IN 是危险操作：只要子查询结果中任意一行的字段为 NULL（比如 SELECT dept_id FROM employees 里有 NULL），整个表达式恒为 UNKNOWN，WHERE 条件直接过滤掉全部结果，静默出错。
NOT EXISTS 没这个问题，它只关心“能不能找到匹配行”，空值不影响布尔逻辑，且仍可走索引关联。例如：
SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'cancelled');
这个查询即使 orders.user_id 有 NULL，也完全不影响语义和性能。
真正该盯住的不是语法选哪个，而是执行计划里有没有 Using semi-join，以及关联字段上有没有可用索引——这两点漏掉一个，EXISTS 就只是看起来高级而已。
