left join后where过滤右表字段等效于inner join，应将条件移至on子句；inner join无结果常因连接字段含null；left join需默认值时用coalesce处理null。
结果不一致不是 bug，是语义差异被误用——关键看你要的是“交集数据”还是“主表全量+可选关联”。
LEFT JOIN 后 WHERE 过滤右表字段，实际等于 INNER JOIN
这是最常踩的坑：写 LEFT JOIN orders o ON u.id = o.user_id，再加 WHERE o.status = 'paid'，结果里根本看不到没下单或未支付的用户。
- 原因：WHERE 在连接完成后执行，会把
o.status为NULL的行（即左表有、右表无匹配）直接过滤掉 - 正确做法是把条件挪进
ON：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 验证方法：查
COUNT(*)和COUNT(o.id)，若两者差距大且你本意是“所有用户”，说明 WHERE 位置错了
INNER JOIN 返回空结果，但你知道左表明明有数据
比如查 orders 和 users，INNER JOIN 没返回任何行，可 SELECT COUNT(*) FROM users 是 1000 条。
- 常见原因：连接字段含
NULL——orders.user_id或users.id有空值，而NULL = NULL永远为 false，无法匹配 - 检查手段：运行
SELECT COUNT(*) FROM orders WHERE user_id IS NULL和SELECT COUNT(*) FROM users WHERE id IS NULL - 临时绕过：用
COALESCE或IS NOT DISTINCT FROM（PostgreSQL）替代等号，但更推荐清洗数据源头
LEFT JOIN 结果出现大量 NULL，但业务上需要默认值
比如 SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id，o.amount 很多是 NULL，但报表要求显示 0。
- 别在应用层判空补 0，容易漏或错位；直接在 SQL 里用
COALESCE(o.amount, 0)或ISNULL(o.amount, 0)（SQL Server） - 聚合时尤其注意：
COUNT(o.id)统计非 NULL 行数，COUNT(*)统计所有行——想算“每个用户下了几单”，必须用前者 - 排序时
ORDER BY o.amount会让NULL排最前或最后（依数据库而定），需显式写ORDER BY COALESCE(o.amount, 0)控制顺序
真正难的不是语法，而是每次写 JOIN 前得问自己一句：这张表是不是我绝对不能丢的主干？如果答案是“是”，那 LEFT JOIN 的 ON 里就不能放右表的业务过滤条件，否则主干就断了。
