EXISTS 一旦找到匹配行即短路退出，NOT EXISTS 必须确认子查询无结果才返回真；二者均为逐行驱动的半连接或反连接，索引生效依赖关联字段索引、外层过滤条件及函数下推能力。
EXISTS 和 NOT EXISTS 的执行逻辑差异
MySQL 用 EXISTS 判断子查询是否返回至少一行，一旦找到就短路退出；NOT EXISTS 则必须确认子查询完全无结果才返回真。这不是“先查完再判断”，而是逐行驱动外层表，对每行执行一次子查询的半连接（semi-join）或反连接（anti-join）——这直接影响索引能否生效。
常见错误是把 NOT EXISTS 当成 LEFT JOIN ... IS NULL 的语法糖，但优化器处理方式不同：前者更倾向使用物化（materialization）或 LooseScan，后者可能走嵌套循环，性能差异可达数倍。
什么时候该用 EXISTS 而不是 IN
IN 在子查询含 NULL 时整个表达式返回 UNKNOWN，结果被过滤掉；EXISTS 不受 NULL 影响。更关键的是性能：
- 子查询结果集大且无索引时，
IN可能触发全表扫描+临时表排序，EXISTS只需命中第一条就停 - 外层表小、内层表大，且内层有合适索引（如
WHERE inner.col = outer.col），EXISTS通常更快 - 子查询带聚合或复杂条件（如
GROUP BY），EXISTS更易被优化器下推条件
示例：查有订单的用户
SELECT * FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id );
注意子查询里写 SELECT 1，不是 SELECT *——避免列解析开销。
NOT EXISTS 优化的三个硬性前提
想让 NOT EXISTS 快，必须同时满足：
- 子查询的关联字段（如
o.user_id = u.id）在内层表上有索引，且索引前导列匹配关联条件 - 外层表不能是全表扫描主力——如果
users表没加WHERE条件，优化器可能放弃半连接改用 Block Nested-Loop - 子查询不能含无法下推的函数，比如
DATE(created_at) = '2024-01-01'会让索引失效，应改写为created_at >= '2024-01-01' AND created_at < '2024-01-02'
若不满足任一条件，NOT EXISTS 可能比 LEFT JOIN ... IS NULL 还慢，建议用 EXPLAIN FORMAT=TREE 看实际执行计划里的 antijoin 或 materialized 标记。
容易被忽略的 NULL 坑和调试方法
NOT EXISTS 对空集返回 TRUE，但若子查询本身因 NULL 导致关联失败（比如 o.user_id 有 NULL），行为仍正确；真正危险的是外层字段为 NULL 时的逻辑错位。例如：
SELECT * FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid' );
如果 u.id 是 NULL，整个 NOT EXISTS 永远为 TRUE（因为 NULL = anything 为 FALSE，子查询无结果）。这种数据质量隐患往往在线上才暴露。
调试建议：
— 先用 EXPLAIN 确认是否走了索引，特别检查 key 和 rows 字段
— 对比 NOT EXISTS 和等价的 LEFT JOIN 的 Handler_read_* 状态值
— 在子查询里加 AND inner_col IS NOT NULL 显式排除空值干扰
