left join 多层后右表字段批量为 null 不是 bug，而是因前层未匹配导致后续 on 条件恒不成立（null = anything 为 unknown），左表行仍保留；关键在 on 字段应优先源自原始左表，筛选条件须写入 on 而非 where，group by 需覆盖完整维度，字段别名与类型必须严格一致。
LEFT JOIN 多层后右表字段批量为 NULL 不是 Bug，是逻辑必然
连续 LEFT JOIN 时，第二层右表的连接结果依赖第一层输出。如果第一层右表（比如 orders）没匹配上，t2.product_id 就是 NULL，那么 ON t2.product_id = t3.id 永远不成立——NULL = anything 判定为 UNKNOWN，不是 TRUE。结果就是 t3 所有字段全为 NULL，但左表行仍在。这不是数据库出错，是你写的关联路径断了。
实操建议：
- 每层
ON的左端字段尽量来自最原始左表（如t1.preferred_product_id），而非前一层右表字段 - 避免写
LEFT JOIN products ON orders.product_id = products.id，改用LEFT JOIN products ON users.preferred_product_id = products.id - 调试时先
SELECT *，观察t2.product_id是否大量为NULL——这是下层失效的前置信号
WHERE 里写了任意右表字段，整个 LEFT JOIN 就退化成 INNER JOIN
SQL 执行顺序固定：FROM → JOIN（ON）→ WHERE。LEFT JOIN 先完成连接，再执行 WHERE 过滤。一旦 WHERE 中出现 t2.status = 'paid' 或 t3.name IS NOT NULL，所有右表字段为 NULL 的行都会被整行踢掉——因为 NULL = 'paid' 是 FALSE，不满足条件。
实操建议：
- 右表筛选条件必须塞进对应
ON子句，用AND连接：例如LEFT JOIN orders ON t1.id = t2.user_id AND t2.status = 'paid' - 真要查“左表有、右表无”，只能用
WHERE t2.user_id IS NULL，且前面不能有任何其他 WHERE 条件干扰 - 用
EXPLAIN对比改前改后rows值：若左表原始行数明显减少，基本可判定是 WHERE 干的
GROUP BY 放在 LEFT JOIN 后却只按左表字段分组，空缺维度被无声压缩
LEFT JOIN 保证左表每行都出现，但 GROUP BY 若只按左表字段（如 month）分组，所有右表没匹配上的行会被压进同一个“空组”。你看到的是 8 行结果，实际左表有 12 行——那 4 个空缺月份被合并了，根本看不出哪几月没数据。
实操建议：
-
GROUP BY必须在JOIN完成之后执行，顺序不能颠倒 - 统计右表存在性要用
COUNT(t2.id)（NULL 不计入），别用COUNT(*)（它只数左表行） - 想强制补全维度（比如 12 个月），得先用 CTE 或子查询构造完整左表：
SELECT '2026-01' AS month UNION SELECT '2026-02' ...，再以此为左表做 LEFT JOIN
多表 JOIN 时字段别名混乱或类型不一致，导致隐式转换或连接失败
别名不统一（如 FROM 用 t1，ON 里写 users.id）、连接字段类型不一致（orders.type 是 VARCHAR(32)，config.type 是 TEXT），都会让优化器无法走索引，甚至触发全表扫描。更隐蔽的是，某些字段名冲突（如 t2.created_at 和 t3.created_at）在 SELECT 中未加前缀，可能直接报错或返回不可预期值。
实操建议：
- 所有
ON中的字段必须带明确表别名，禁止裸字段 - 维度表（如
config）的连接字段务必建索引，且与事实表字段类型、长度、字符集严格一致 - 写完 JOIN 先跑
EXPLAIN，确认key和rows是否合理；若type显示ALL，大概率是索引没生效
