left join后查不到“未匹配”记录，主因是where中误写右表非空条件导致左表行被过滤；正确做法是将右表筛选条件移入on子句，并用where右表外键is null判断无匹配行。
LEFT JOIN 后 WHERE 子句写错，查不到“未匹配”记录
很多人写 LEFT JOIN 想找左表有、右表没有的记录，却在 WHERE 里直接写 right_table.id IS NULL，结果返回空——其实不是逻辑错，是执行顺序导致的：JOIN 先算完，再过滤。如果右表字段在 ON 条件里没参与关联（比如用了错误字段），LEFT JOIN 仍会生成带 NULL 的行，但后续 WHERE 可能意外过滤掉这些行。
关键点：必须把“右表无匹配”的判断放在 WHERE，且确保 ON 条件正确关联主键/外键；否则 NULL 行压根不会出现。
-
ON必须用可关联的字段，比如users.id = orders.user_id，不能写成users.name = orders.user_name（易因空格、大小写、NULL 值失效） - 如果右表有多个匹配行，
LEFT JOIN会返回多行，IS NULL判断仍有效，但结果行数可能比左表多 - 避免在
WHERE中对右表字段加非空约束（如orders.status = 'paid'），这会让整行被过滤，包括本该保留的NULL行
正确写法：ON 关联 + WHERE IS NULL
标准模式就是两步：先用 ON 定义关联逻辑，再用 WHERE 筛出右表字段全为 NULL 的行。这是唯一可靠方式，不依赖数据库优化器或统计信息。
SELECT u.id, u.email FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.user_id IS NULL;
注意：o.user_id IS NULL 比 o.id IS NULL 更稳妥，因为有些数据库允许 orders.id 为 NULL（虽然不合理），而外键字段 user_id 在无匹配时一定为 NULL。
- 若右表有联合主键（如
(order_id, item_id)），需全部判NULL：WHERE o.order_id IS NULL AND o.item_id IS NULL - MySQL 8.0+ 和 PostgreSQL 支持
NOT EXISTS替代，语义更清晰，性能通常相当 - 别用
NOT IN (SELECT ...)，子查询结果含NULL会导致整个条件返回UNKNOWN，结果为空
LEFT JOIN vs. NOT EXISTS：性能与语义差异
当右表数据量大、且关联字段无索引时，LEFT JOIN ... WHERE IS NULL 可能比 NOT EXISTS 更慢，因为前者要构造临时连接结果集，后者可短路退出。
但二者语义不完全等价：NOT EXISTS 只关心是否存在，不关心右表其他字段；而 LEFT JOIN 若在 SELECT 中引用右表字段，即使加了 WHERE IS NULL，也可能因隐式类型转换或 COLLATION 导致意外行为。
- PostgreSQL 对两者优化较好，差异小；MySQL 5.7 下
NOT EXISTS常更快 - 如果需要同时查左表字段和右表某固定值（如默认状态），
LEFT JOIN更自然；纯“有无”判断，NOT EXISTS更安全 - SQL Server 中，
LEFT JOIN在某些统计信息陈旧场景下可能走错执行计划，NOT EXISTS更稳定
容易忽略的 NULL 处理细节
最常踩的坑不是语法，而是没意识到：右表字段本身可能存 NULL，而非因未匹配导致。比如 orders.shipped_at 是可空字段，它为 NULL 不代表没订单，只代表没发货。
所以判断“未匹配”，必须用参与关联的字段（通常是外键），而不是业务字段。否则结果不可靠。
- 检查右表外键字段是否定义为
NOT NULL：如果是，IS NULL就只来自未匹配；如果不是，得先确认该字段在业务中是否允许人为置NULL - 某些 ORM（如 Django ORM）生成的
LEFT JOIN查询会自动加IS NOT NULL过滤，需手动绕过或改用exclude()配合exists - 如果左表本身有
NULL主键（极不推荐），LEFT JOIN结果中这部分行的右表字段也全是NULL，但它们不属于“未匹配”，而是脏数据
真正要抓的“未匹配”，永远基于外键字段是否为 NULL，而不是任何业务字段的空值状态。
