LEFT JOIN后NULL字段用COALESCE()或CASE WHEN填默认值，WHERE过滤右表字段会使LEFT JOIN退化为INNER JOIN，应移至ON子句；JOIN顺序决定主表，users须在最左；右表JOIN字段需有匹配索引。
LEFT JOIN后NULL字段怎么填默认值
LEFT JOIN天然会留下右表缺失时的NULL，但业务常要求补成0、'-'或'未知'——不能靠应用层兜底，得在SQL里一次性搞定。
核心就两条路：COALESCE() 和 CASE WHEN，前者更简洁，后者更灵活。
-
COALESCE()按顺序返回第一个非NULL值，比如COALESCE(t2.status, '待处理')，适合单层兜底 - 需要条件判断（如“金额为NULL则填0，但币种为USD时填'N/A'”）就得用
CASE WHEN t2.amount IS NULL THEN 0 ELSE t2.amount END - 别用
IFNULL()或ISNULL()——它们不是标准SQL，MySQL和SQL Server行为不一致，跨库迁移容易翻车
LEFT JOIN补全失败：常见WHERE条件陷阱
写完LEFT JOIN，一加WHERE就变INNER JOIN，数据突然少了一半——这是最典型的误用。
问题出在WHERE过滤了右表字段，把本该保留的左表空匹配行给筛掉了。
- 错误写法：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'→ 实际等效于INNER JOIN - 正确做法：把右表过滤条件挪到
ON子句里，LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 如果必须用
WHERE做全局过滤（比如只查2024年用户），确保它只作用于左表字段，或用子查询先筛右表
多表LEFT JOIN顺序影响补全结果吗
影响很大。JOIN顺序决定“主表”是谁，而LEFT JOIN永远以左侧表为基准补全。
比如想补全用户信息+订单+订单详情，但又想保留没下过单的用户，就必须让users始终在最左边。
- 正确链式：
users LEFT JOIN orders ON ... LEFT JOIN order_items ON ...→ 用户全量保留 - 错误链式：
orders LEFT JOIN users ON ... LEFT JOIN order_items ON ...→ 主表变成订单，用户反成被补全方，没订单的用户直接消失 - 别依赖优化器重排顺序，显式控制JOIN顺序是最稳妥的做法
性能警告：LEFT JOIN补全遇上大表COUNT或GROUP BY
补全本身不慢，但后续聚合操作容易触发全表扫描，尤其当右表没索引或JOIN键选择性差时。
典型症状是执行计划里出现Using temporary; Using filesort，或者EXPLAIN显示rows远超预期。
- 确保JOIN字段（如
user_id）在右表上有索引，且类型与左表完全一致（比如都是BIGINT，别一边INT一边BIGINT） - 避免在LEFT JOIN后的右表字段上做
GROUP BY，除非真需要按右表分组；否则优先GROUP BY左表字段 - 如果只是统计“每个用户有几笔订单”，用
COUNT(o.id)而不是COUNT(*)，前者自动忽略NULL，语义更准，也更易走索引
补全逻辑越靠近业务需求越容易出错——比如该用COALESCE却写了IF，或者在WHERE里悄悄过滤掉NULL行。这些地方没有报错，但数据就是不对，查起来特别费时间。
