not exists在某些场景下比left join慢，是因为右表无合适索引时优化器可能退化为嵌套循环，而left join…is null更易触发哈希连接或排序合并；改写需确保关联键非空，并将子查询条件移入on子句，避免where中误判导致逻辑错误。

为什么NOT EXISTS在某些场景下比LEFT JOIN慢？

数据库优化器对 NOT EXISTS 的执行计划有时会退化为嵌套循环（尤其是右表无合适索引时），而 LEFT JOIN ... IS NULL 更容易触发哈希连接或排序合并，尤其在大表关联时差异明显。但注意：这不是绝对的，关键看驱动表选择、索引覆盖和统计信息准确性。

LEFT JOIN改写NOT EXISTS的核心模式

把 NOT EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id) 改成 LEFT JOIN t2 ON t1.id = t2.id WHERE t2.id IS NULL。必须确保 t2.id 是非空列（如主键或定义了 NOT NULL），否则 IS NULL 判断可能漏掉真实匹配行。

常见错误现象：LEFT JOIN 后用 t2.some_column IS NULL 判断，但该列本身允许 NULL —— 这会导致误判，结果集变大。

• 只对关联键（如主键、唯一索引列）做 IS NULL 检查
• 若原 NOT EXISTS 中有额外条件（如 t2.status = 'active'），需把它移到 ON 子句，而非 WHERE
• 避免在 LEFT JOIN 后的 WHERE 中对左表字段加条件，否则可能意外转成内连接

实际改写示例与陷阱

原始低效语句：

SELECT t1.name FROM users t1
WHERE NOT EXISTS (
  SELECT 1 FROM orders t2 
  WHERE t2.user_id = t1.id AND t2.status = 'paid'
);

正确改写：

SELECT t1.name FROM users t1
LEFT JOIN orders t2 ON t1.id = t2.user_id AND t2.status = 'paid'
WHERE t2.user_id IS NULL;

错误改写（常见坑）：

-- ❌ 把 status 条件放 WHERE，导致 LEFT JOIN 失效
LEFT JOIN orders t2 ON t1.id = t2.user_id
WHERE t2.status = 'paid' AND t2.user_id IS NULL;

这个写法实际等价于 INNER JOIN，完全偏离原意。

什么时候不该强行改写？

如果右表数据量极小（比如几十行的配置表），或 NOT EXISTS 已命中高效索引（如 (user_id, status) 联合索引），改写后反而可能因连接开销变慢。执行计划里重点看 rows 预估和 type（是否用了 range 或 ref）。另外，SQL Server 对 NOT EXISTS 优化得较好，而 MySQL 5.7 及以前版本更倾向从 LEFT JOIN 中受益。

真正要盯住的，是 EXPLAIN 输出里 t2 表的访问类型和是否用到索引，而不是语法看起来“更直观”。