NOT EXISTS 更优：语义直观、NULL 安全、条件扩展不易出错、支持复杂子查询，且维护风险更低。
NOT EXISTS 的语义更贴近业务意图
当你想表达“找那些在 A 表里、但在 B 表里找不到对应记录的行”，NOT EXISTS 直接写成 WHERE NOT EXISTS (SELECT 1 FROM b WHERE b.id = a.id)，读起来就是“对每行 a，检查 b 中有没有匹配的 id”——这和人脑推理顺序一致。而 LEFT JOIN ... WHERE b.id IS NULL 是个“迂回战术”：先强行拼一遍，再筛掉拼上的，中间多了一层“构造空值”的隐含步骤。团队新人或交接时，前者更容易一眼看懂逻辑，后者容易被误读为“是不是漏写了 ON 条件”或者“为什么这里用 IS NULL 而不是 = NULL”。
LEFT JOIN 容易因字段 NULL 值引入静默错误
如果右表连接字段（比如 users.id）允许为 NULL，LEFT JOIN 会把所有左表行都连上，且当右表该字段为 NULL 时，WHERE u.id IS NULL 就会把本应匹配成功的行也判为“不存在”。这不是 bug，是 SQL 对 NULL 的三值逻辑决定的。而 NOT EXISTS 完全不依赖右表字段是否为 NULL，它只关心子查询是否返回结果行——只要子查询里写了正确的关联条件（如 t2.user_id = t1.user_id），NULL 值就不会干扰判断。这种稳定性让后续加字段、改约束、迁移数据时更少出意外。
修改条件时 NOT EXISTS 不易破坏原有逻辑
当需求从“查用户没登录过的订单”变成“查用户没登录过且状态非已取消的订单”，你只需在子查询的 WHERE 里加条件：AND login.status != 'cancelled'。而 LEFT JOIN 写法中，新手常把新条件错塞进 ON 子句（比如 ON u.id = o.user_id AND u.status != 'cancelled'），这会导致右表过滤提前发生，把本该保留的左表行直接踢掉——结果变少但无报错，极难排查。正确做法是把业务条件放 WHERE，可一旦忘了，维护成本就上去了。
子查询结构天然支持复杂过滤逻辑
当排除规则来自聚合、多表关联或带函数的子查询（例如“排除过去 7 天有支付失败记录的用户”），NOT EXISTS 只需把整个逻辑包进子查询里，外层完全不动；而 LEFT JOIN 很可能要拉多张表进来，ON 条件变得冗长，还容易因连接顺序或去重问题导致结果膨胀。更麻烦的是，如果子查询里用了 GROUP BY 或窗口函数，LEFT JOIN 几乎无法直接复用，必须重写整个连接结构。
真正难维护的从来不是语法本身，而是当某天有人给右表字段加了 DEFAULT NULL、或把 NOT IN 改成 LEFT JOIN 却没同步补索引、又或者在子查询里漏写关联列——这些坑在 NOT EXISTS 里要么根本不会出现，要么一执行就报错，而不是悄悄返回错数据。
