LEFT JOIN 后 WHERE col IS NULL 查不到“没匹配的行”，是因为 WHERE 在 JOIN 之后执行，若 col 非右表关联字段（如主键/外键）或被 ON 提前过滤，则无法区分“无匹配”与“字段本为空”；正确做法是 WHERE 右表关联字段 IS NULL，且该字段需建索引以保障性能。
LEFT JOIN 后 WHERE col IS NULL 为什么查不到“没匹配的行”？
因为
条件在
之后执行，会把
生成的
行过滤掉——除非你明确写的是
，且该字段来自右表（被左连接的那张表）。
常见错误现象：
写了
，又在
里加了右表字段的非空条件（比如
），结果变成隐式
，根本看不到缺失匹配的行。
正确做法：筛选“无匹配”，必须把右表字段的
判断放在
，且该字段不能在
子句中被提前过滤
更安全的写法是把右表的过滤条件挪到
里（如
），再用
找没连上的左表行
注意：
要是右表中对应左表主键的外键字段，不是随便选个
字段
LEFT JOIN + IS NULL 的典型写法和易错字段选择
核心逻辑是：左表每行都保留，右表没匹配时整行填
；所以得挑一个“右表一定有值、但没匹配时强制为
”的字段来判空。
使用场景：查订单表里没有发货记录的订单、用户表里没登录日志的用户、配置表里未启用的模块等。
优先选右表的主键或外键字段，比如
或
—— 它们在没匹配时一定是
别用右表的可空业务字段（如
），它本身可能存
，无法区分“没匹配”和“匹配了但字段为空”
如果右表用了复合主键，得用全部字段组合判空，例如
示例：
性能影响：NULL 检查会不会拖慢查询？
会，但只在没索引时明显。数据库优化器对
的处理依赖索引覆盖程度。
参数差异：
MySQL 8.0+ 和 PostgreSQL 对
支持索引扫描，但 SQLite 和旧版 MySQL 可能走全表扫描。
确保右表的关联字段（如
）建了索引，否则
本身就会慢，
只是雪上加霜
避免在
中对右表字段做函数操作，比如
，这会让索引失效
如果数据量极大（千万级+），考虑先用
替代，有时执行计划更优（尤其当右表有复杂过滤时）
替代方案：NOT EXISTS 比 LEFT JOIN 更直观吗？
语义上更贴近“找不存在的记录”，且天然规避了
的字段选择陷阱。
常见错误现象：
用
时，子查询结果含
会导致整个条件返回空集 —— 这是 SQL 三值逻辑坑，必须避开。
不受子查询
影响，推荐作为首选替代
写法简洁：
注意子查询里别漏
关联条件，否则变成“只要右表有任意一行就排除左表所有行”
复杂点在于子查询不能直接引用左表的计算字段（比如
在某些数据库里受限），这时还是得回到
。
WHEREJOINLEFT JOINNULLWHERE right_table.id IS NULLLEFT JOINWHEREWHERE r.status = 'active'INNER JOINIS NULLWHEREONONON l.id = r.l_id AND r.status = 'active'WHERE r.l_id IS NULLr.l_idNULLNULLNULLshipments.order_idlogs.user_idNULLshipments.tracking_noNULLWHERE r.a IS NULL AND r.b IS NULLSELECT u.id, u.name
FROM users u
LEFT JOIN login_logs l ON u.id = l.user_id
WHERE l.user_id IS NULL;IS NULLIS NULLlogin_logs.user_idLEFT JOINIS NULLWHEREWHERE COALESCE(r.id, 0) = 0NOT EXISTSLEFT JOINNOT IN (SELECT ...)NULLNOT EXISTSNULLSELECT u.id, u.name
FROM users u
WHERE NOT EXISTS (
SELECT 1 FROM login_logs l WHERE l.user_id = u.id
);WHEREu.created_at::dateLEFT JOIN