left join失效是因为where中对右表字段的条件过滤了null行，等价于inner join；应将右表条件移至on子句，多层join需确保连接字段来源可靠，group by必须在join之后执行。
WHERE里写了右表字段，LEFT JOIN就失效了
LEFT JOIN本身不会丢左表数据，但一旦你在WHERE子句里对右表字段加条件（比如t2.status = 'active'），数据库会在连接完成后再过滤——而右表没匹配上的行，所有t2.*字段都是NULL，NULL = 'active'判定为FALSE，整行被踢掉。结果等价于INNER JOIN。
实操建议：
- 把右表筛选条件挪进
ON子句，用AND连接：例如LEFT JOIN orders t2 ON t1.id = t2.user_id AND t2.status = 'active' - 如果真要查“左表有、右表无”的情况，条件必须写成
WHERE t2.user_id IS NULL，不能写= NULL - 调试时先跑
SELECT *，观察右表字段是否批量为NULL——这是匹配失败的明确信号
多层LEFT JOIN时别让上层NULL污染下层连接
连续LEFT JOIN时，第二层依赖第一层结果。如果t2.product_id是NULL（比如用户没下单），那么ON t2.product_id = t3.id必然失败，t3字段全NULL——这不是bug，是逻辑必然。
实操建议：
- 每层
JOIN的连接字段尽量来自最左侧主表，比如用t1.preferred_product_id而非t2.product_id去连products - 避免跳过中间表直接拉远端字段，例如不能写
LEFT JOIN products p ON u.preferred_product_id = p.id绕过orders表，语义断裂 - 所有表别名在
FROM和ON中必须一致，不能前边用u，后边写users.id
GROUP BY之前必须完成LEFT JOIN
LEFT JOIN必须在GROUP BY之前执行。如果顺序写反（比如先GROUP BY再LEFT JOIN），原始行已被压缩，右表补空的基础就没了——多数数据库会直接报语法错误，少数允许执行的引擎结果不可控。
实操建议：
- 正确顺序永远是：
FROM → LEFT JOIN → GROUP BY - 如果
SELECT中引用右表字段（如t2.status），它必须出现在GROUP BY里，或用聚合函数包裹，例如MAX(t2.status) -
COUNT(t2.id)返回0说明该分组右表无数据，不是丢失，是正确结果；想补零要用COALESCE(COUNT(t2.id), 0)
SELECT中取右表字段时没做NULL兜底
LEFT JOIN未匹配时，右表字段全为NULL。直接参与计算或拼接会引发意外：字符串拼接得NULL，数值运算中断，WHERE t2.created_at > '2024-01-01'这种条件对NULL永远返回FALSE。
实操建议：
- 金额类字段用
COALESCE(t2.amount, 0)转默认值 - 文本类字段用
COALESCE(t2.name, '未下单')提升可读性 - 避免在
WHERE里写t2.field > xxx这类隐含IS NOT NULL前提的条件，除非显式加上AND t2.field IS NOT NULL
product_id允许为空，那商品信息必然丢失——这时得回退到用户表的preferred_product_id做独立关联，而不是硬扛NULL链。
