LEFT JOIN实现反连接唯一可靠写法是LEFT JOIN + WHERE右表连接字段IS NULL，必须用外键字段（如o.user_id）而非主键（o.id）判空，因主键非空导致条件永假；该字段须为NOT NULL外键、等值连接、且建有索引，否则结果错误或性能骤降。
LEFT JOIN 实现反连接唯一可靠写法是：LEFT JOIN + WHERE 右表连接字段 IS NULL，且该字段必须是外键或关联字段，不能是右表主键或任意其他字段。
为什么必须用 o.user_id IS NULL 而不是 o.id IS NULL
因为反连接要判断的是“有没有匹配上”，而匹配依据是连接条件（如 u.id = o.user_id）。只有被用于连接的字段（o.user_id）为 NULL，才说明左表某行在右表中找不到对应记录。若误判 o.id IS NULL：
-
o.id是主键，根本不可能为NULL，WHERE 条件永远不成立，结果为空 - 即使右表主键允许
NULL（极少见），它和“是否匹配”完全无关，逻辑断裂 - 执行计划可能无法优化为 Hash Anti Join，性能直线下滑
LEFT JOIN 反连接的三个硬性前提
这个写法看似简单，但缺一不可，否则结果错、性能差、兼容性崩：
- 右表的连接字段（如
orders.user_id）必须是外键，且定义为NOT NULL；如果允许NULL，IS NULL就会把“匹配了但值为NULL”和“根本没匹配”混为一谈 - 连接条件必须是等值比较（
=），不能是!=、LIKE、函数包裹（如COALESCE(o.user_id, 0)），否则索引失效，也大概率阻止优化器生成 Anti Join 计划 - 右表连接字段上必须有索引；没有索引时，LEFT JOIN 会退化为嵌套循环，大表下秒变分钟级
常见错误写法与真实报错现象
这些写法在开发中高频出现，但实际运行时要么结果不对，要么慢得离谱：
-
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL→ 返回空结果，即使存在无订单用户（因o.id主键非空） -
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL OR o.user_id = 0→OR破坏谓词下推，全表扫描风险极高 -
SELECT u.* FROM users u LEFT JOIN orders o ON u.id = COALESCE(o.user_id, -1) WHERE o.user_id IS NULL→ 连接条件含函数，索引彻底失效，MySQL 甚至拒绝使用o.user_id上的索引
什么时候宁可多写几行也要换 NOT EXISTS
当右表连接字段允许 NULL，或者你无法确认其约束时，LEFT JOIN + IS NULL 就不再安全。这时必须切到 NOT EXISTS：
- 子查询里写
SELECT 1，不是SELECT *或具体字段，避免无谓数据传输 - 子查询 WHERE 中必须有明确关联（如
o.user_id = u.id），漏掉就变成检查“右表是否存在任意一行”，结果全错 - 哪怕右表字段全是
NOT NULL，在 MySQL 5.7 或某些复杂嵌套场景下，NOT EXISTS的执行计划也更稳定，不易被优化器误判
真正难的不是写出语法，而是判断右表那个字段到底能不能信——它是不是真由外键约束保证非空，还是只是“我们觉得它应该不为空”。这种模糊地带，NOT EXISTS 是唯一的免责选项。
