sql左反连接本质是返回左表中在右表完全不匹配的记录，推荐用not exists或left join...where右表连接字段is null实现，禁用not in以防null导致结果为空。
SQL左反连接的本质是找“不在另一张表里的记录”
左反连接（Anti-Join）不是标准 SQL 关键字，而是逻辑需求：返回左表中那些在右表里**完全不匹配**的行。常见场景包括“查出没下过单的用户”“找出未被引用的配置项”。核心思路只有两个可靠路径：NOT EXISTS 和 LEFT JOIN ... WHERE right_col IS NULL，其他写法（如 NOT IN）在含 NULL 时极易出错。
用 NOT EXISTS 实现安全、语义清晰的 Anti-Join
NOT EXISTS 是最推荐的方式，它天然规避 NULL 带来的陷阱，且执行计划通常更可控。关键点在于子查询必须关联外层，并只关心是否存在，不返回实际数据。
示例：查出所有没有订单的用户
SELECT u.id, u.name FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id );
-
SELECT 1是惯用写法，子查询只判断存在性，不取字段值 - 子查询中的
o.user_id = u.id是**相关子查询**的必要关联，漏掉就变成全表扫描或恒假 - 如果
orders.user_id允许NULL，NOT EXISTS依然正确；而NOT IN (SELECT user_id FROM orders)会因NULL导致整个结果为空 - 确保
orders.user_id有索引，否则性能会急剧下降
用 LEFT JOIN + IS NULL 实现但要注意连接条件和 NULL 判断位置
这个方案直观，但容易写错：必须在 ON 子句中写连接条件，在 WHERE 中判 NULL，且只能判右表的**被连接字段**（通常是外键）是否为 NULL。
错误写法（常见坑）：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL; -- ❌ 错！o.id 可能为 NULL 即使匹配成功（比如 o.id 允许 NULL）
正确写法：
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL; -- ✅ 对！o.user_id 是连接字段，为 NULL 才说明没匹配
-
o.user_id IS NULL必须出现在WHERE，不能放在ON里，否则逻辑失效 - 如果右表连接字段本身允许
NULL（比如user_id是可空外键），那这个字段为NULL就无法区分“没匹配”和“匹配了但值为 NULL”，此时必须改用NOT EXISTS - 该写法在某些旧版 MySQL 或复杂嵌套下，优化器可能不如
NOT EXISTS稳定
别碰 NOT IN —— 除非你 100% 确保右表字段非空
NOT IN 看似简洁，但只要右表子查询结果中有一个 NULL，整个条件就恒为 UNKNOWN，最终结果集为空。这不是 bug，是三值逻辑的必然结果。
例如：
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders); -- 若 orders 中任意 user_id 为 NULL，结果必为空
- 即使加
WHERE user_id IS NOT NULL过滤，也得额外确认子查询不会漏数据 - 多数情况下，它比
NOT EXISTS多一次全量扫描，性能更差 - 唯一可用场景：右表字段定义为
NOT NULL且业务上绝对不可能插入NULL，但这种保证很难长期维持
真正难处理的是右表字段本身可空又必须用 LEFT JOIN 的情况——这时候得先明确业务语义：那个 NULL 到底算“有效记录”还是“无效占位”，再决定是否清洗数据或换用 EXISTS 逻辑。
