NOT EXISTS 的执行逻辑是“确认子查询不返回任何行”，而非值比较；它对主表每行执行一次关联子查询，仅当子查询为空时保留该行，关联条件必须写在子查询WHERE中且需索引支持。
NOT EXISTS 的执行逻辑不是“排除值”，而是“确认不存在”
很多人写 NOT EXISTS 时下意识把它当成了 NOT IN 的替代品，结果查不到数据还反复检查字段名——其实根本不是字段问题。它不比较值，只判断子查询是否返回行：NOT EXISTS 对主表每一行，执行一次子查询；只要子查询空，这行就留下。
常见错误现象：子查询里漏写关联条件，比如写成 SELECT 1 FROM orders WHERE month = '202609'（没关联到主表），结果整张主表被全过滤掉——因为子查询对每行都跑一遍完全相同的、不带参数的查询，要么永远有结果，要么永远没结果。
- 关联必须写在子查询的
WHERE子句里，且用等值比较（如o.user_id = u.id） -
SELECT 1是惯用写法，但写SELECT *或SELECT NULL都不影响逻辑 - 子查询里不能出现主表未定义的别名，也不能引用主表的聚合字段（如
MAX(u.id)）
业务条件必须塞进子查询 WHERE，不能放主查询
你想查“没在 2026 年 9 月下单的用户”，条件 o.month = '202609' 必须和关联条件一起放在子查询里。如果错放到主查询 WHERE，数据库会先执行 NOT EXISTS 得到一批用户，再拿这批用户去筛订单时间——但这时订单时间已经不在子查询上下文中了，逻辑彻底崩坏。
错误写法：SELECT u.* FROM users u WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) AND o.month = '202609' —— 这里 o.month 在主查询作用域根本不存在，直接报错。
- 正确写法：把
o.month = '202609'放进子查询WHERE，与关联条件用AND连接 - 如果要加多个业务条件（如状态、类型），全部堆进子查询
WHERE，不要拆开 - 避免在子查询中对索引字段做函数操作，例如
DATE(o.created_at) = '2026-09-01'会让索引失效
索引建在哪？必须覆盖子查询里的所有等值条件
数据库优化器只有看到子查询能走索引快速探查，才可能生成 NESTED LOOPS ANTI 或 HASH JOIN ANTI。否则它可能退化成对右表逐行扫描，性能断崖下跌。
假设子查询是 SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'shipped'，那最优索引是 orders(user_id, status) —— 字段顺序必须匹配，user_id 在前，因为它是关联主表的等值字段。
- 如果只建了
orders(status)单列索引，优化器大概率放弃使用 - 复合索引里不要包含
TEXT或超长VARCHAR字段，否则索引体积膨胀，反而拖慢探查 - PostgreSQL 和 MySQL 8.0+ 能利用索引只查键值（Index Only Scan），但前提是索引已包含所有需访问字段，而
NOT EXISTS只查键，所以通常够用
为什么 NOT EXISTS 比 LEFT JOIN IS NULL 更少翻车
核心差异在 NULL 处理和执行路径。LEFT JOIN 先拼出完整中间结果，再筛 IS NULL；NOT EXISTS 从不构造中间行，只做存在性判断。这意味着：
- 右表字段允许 NULL 不影响结果：即使
orders.user_id有 NULL 值，NOT EXISTS仍能正确识别“无匹配” - 不会因右表宽字段（如含大
JSONB或TEXT）导致内存暴涨或临时磁盘写入 - 执行计划里更容易观察到
ANTI JOIN节点，而LEFT JOIN ... IS NULL常显示为普通Hash Join+Filter
真正容易被忽略的是统计信息。如果右表行数预估严重偏低（比如实际 500 万行，优化器以为只有 5 万），它可能拒绝反连接，强行改用嵌套循环逐行 FILTER —— 此时哪怕语法全对，性能也极差。定期 ANALYZE 表，比调优 SQL 本身更关键。
