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