LEFT JOIN + WHERE 右表连接字段 IS NULL 是筛选左表独有记录的唯一可靠方式；ON中写IS NULL会退化为INNER JOIN，NOT IN因NULL值失效，NOT EXISTS语义等价但可读性差。
LEFT JOIN + IS NULL 是唯一可靠方式
想从左表中筛出“右表完全没匹配上”的记录，不能只靠 LEFT JOIN，必须配合 WHERE 右表主键 IS NULL。很多人误以为加个 ON 1=0 或漏写 WHERE 条件就能实现，结果返回的是左表全量数据或空集——这根本不是“独有”，只是连接失效。
为什么不能用 WHERE 条件写在 ON 里
ON 子句只控制连接逻辑，不决定最终输出行；WHERE 才真正过滤结果集。如果把 右表.id IS NULL 错写进 ON，会导致 LEFT JOIN 退化为普通 JOIN，甚至语法报错（取决于数据库）。
常见错误写法：
SELECT a.* FROM table_a a LEFT JOIN table_b b ON a.id = b.id AND b.id IS NULL
这段实际等价于 INNER JOIN，因为 b.id IS NULL 在连接时永远不成立（除非 b.id 允许 NULL 且真有 NULL 值，但那不是“无匹配”而是“匹配到 NULL”）。
标准写法与关键细节
正确结构是：先 LEFT JOIN，再用 WHERE 检查右表关联字段是否为 NULL。注意以下几点：
- 必须检查右表的 被 JOIN 的字段（通常是主键或外键），不是随便选一个字段 —— 比如用
b.name IS NULL不可靠，因为name本身可能允许 NULL - 如果右表连接字段是复合主键，要全部判
NULL：WHERE b.id IS NULL AND b.type IS NULL - 某些数据库（如 MySQL 5.7+）对
STRICT_TRANS_TABLES模式敏感，若右表字段定义为NOT NULL，优化器可能提前剪枝，但行为不跨库保证，别依赖
示例：
SELECT a.* FROM users a LEFT JOIN orders b ON a.id = b.user_id WHERE b.user_id IS NULL
性能和替代方案的现实考量
这个写法在大多数场景下可读性强、语义明确，但要注意：
- 右表连接字段如果没有索引，
LEFT JOIN会变慢，尤其数据量大时 —— 确保b.user_id有索引 -
NOT EXISTS语义等价且有时更快（尤其右表很大、左表小时），但可读性略低：SELECT * FROM users a WHERE NOT EXISTS (SELECT 1 FROM orders b WHERE b.user_id = a.id) -
NOT IN看似简洁，但只要右表该字段含NULL，整条查询就返回空结果 —— 这是个经典陷阱，务必避开
真正容易被忽略的是：LEFT JOIN 的“独有”判断，本质依赖右表连接字段的 NULL 含义是否干净。如果业务里右表的外键字段本身就允许 NULL 并用于标记某种状态，那 IS NULL 就不再代表“未匹配”，得换字段或加额外条件。
