NOT EXISTS 比 LEFT JOIN ... IS NULL 快，因其采用半连接，找到匹配即终止且不生成中间结果；而后者需全量关联再过滤，易产生大体积中间数据，尤其右表无索引或字段宽时。
LEFT JOIN ... IS NULL 为什么比 NOT EXISTS 慢？
因为 LEFT JOIN 会先全量关联再过滤，即使你只想要“不存在”的记录，数据库也得把所有匹配行构造出来，再逐行判断 IS NULL；而 NOT EXISTS 是半连接（semi-join），一旦子查询找到一个匹配就立刻放弃，不生成中间结果。
常见错误现象：LEFT JOIN 在右表有大量重复或宽字段时，执行计划里出现大体积的 Hash Right Join 或巨量 Materialize，NOT EXISTS 则常走 Index Only Scan 或 Nested Loop Anti Join。
- 右表无索引时，两者都可能慢，但
NOT EXISTS至少不会放大中间数据量 - 右表有合适索引（如
ON b.a_id = a.id的b(a_id)），NOT EXISTS能直接用索引探查，LEFT JOIN还要回表或扫描 - PostgreSQL 12+ 对
NOT EXISTS有 anti-join 优化，但对LEFT JOIN ... IS NULL不自动转成 anti-join，除非写法完全等价且统计信息充分
MySQL 8.0 下 NOT EXISTS 被优化器忽略索引？
不是语法问题，是子查询里用了非相关列或函数导致索引失效。比如 NOT EXISTS (SELECT 1 FROM b WHERE b.a_id = a.id AND b.status = 'active')，如果 b(a_id, status) 复合索引存在，通常能用；但如果写成 b.status LIKE 'act%' 或 UPPER(b.status) = 'ACTIVE'，索引就废了。
使用场景：排查时直接看 EXPLAIN FORMAT=TREE 输出里的 rows_examined_per_scan 和是否出现 Using index condition。
- 确保子查询中关联条件是纯等值，且字段顺序匹配复合索引前缀
- 避免在子查询
WHERE里对索引字段做计算、类型转换或模糊前导通配（'%xxx'） - MySQL 对
NOT EXISTS的物化（materialization）策略较保守，若子查询返回行数预估 > 100，可能退化为临时表，此时加STRAIGHT_JOIN强制驱动表顺序有时更稳
SQL Server 中 LEFT JOIN ... IS NULL 触发 Nested Loop 扫描全表？
当左表小、右表大，且右表缺失有效索引时，SQL Server 优化器可能误判成本，选 Nested Loops 驱动右表全扫描 —— 每次拿左表一行，就扫一遍右表找匹配，O(n×m) 级别开销。
性能影响明显：1000 行左表 × 100 万行右表 = 十亿次探查；而 NOT EXISTS 在同样条件下大概率走 Index Seek + Top 1，实际只查最多 1000 次索引页。
- 检查执行计划里右表操作符是否标有
Actual Number of Rows = 0但Estimated Number of Rows很高，这是统计信息过期的典型信号 - 强制用
OPTION (RECOMPILE)让参数嗅探生效，尤其当a.id是变量而非字面量时 - SQL Server 2019+ 支持
NOT EXISTS的批处理模式加速（Batch Mode on Rowstore），但需列存储索引或开启 CTFP，普通 B-tree 上不生效
PostgreSQL 中 NOT EXISTS 子查询含 LIMIT 会出错？
会报错：ERROR: LIMIT is not allowed in subqueries used as expressions。PostgreSQL 不允许在 NOT EXISTS 的子查询里写 LIMIT，哪怕只是 LIMIT 1 —— 它认为这破坏语义确定性（理论上只要有一行就足够否定存在性，但语法层禁止显式限制）。
正确做法是去掉 LIMIT，依赖优化器自动终止。PostgreSQL 的 NOT EXISTS 子查询天然就是“找到第一个就停”，加 LIMIT 1 反而让计划器绕过 anti-join 优化路径，降级成普通嵌套循环。
- 不要手动加
LIMIT，也不要用SELECT 1 FROM ... LIMIT 1替代SELECT 1 FROM ... - 如果子查询本身很重（比如带复杂 JOIN），优先给关联字段建索引，而不是靠
LIMIT压行数 - 想确认是否真用了 anti-join？看
EXPLAIN (ANALYZE)输出里有没有Anti Join字样，以及右表是否显示Rows Removed by Filter: xxx为 0
反向排除最怕的不是写法多难，而是默认以为“LEFT JOIN 更直观”就跳过执行计划验证 —— 实际上同一逻辑，不同写法触发的物理算子可能差两个数量级。
