LEFT JOIN后WHERE过滤右表字段会导致左表记录丢失，因执行顺序是先连接后过滤；应将右表条件移至ON子句或显式允许NULL；多源聚合需JOIN前分组防笛卡尔积；MySQL无FULL OUTER JOIN，可用UNION拼接两个LEFT JOIN；算术运算须用COALESCE兜底防NULL传播。
LEFT JOIN后WHERE过滤右表字段等于丢数据
这是最隐蔽也最常复现的问题：明明写了LEFT JOIN，结果左表部分记录还是不见了。根本原因是SQL执行顺序是先完成连接，再执行WHERE过滤。一旦WHERE里出现对右表字段的非空判断（比如WHERE orders.status = 'paid'），所有右表为NULL的行（即左表无匹配）就会被整行剔除。
实操建议：
- 把右表筛选条件挪进
ON子句：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid' - 如果必须用
WHERE，得显式允许NULL：WHERE orders.status = 'paid' OR orders.status IS NULL，但语义通常已偏离原意 - 用
EXPLAIN对比改前改后rows值，确认左表原始行数是否被截断
多源聚合结果JOIN前没分组，导致COUNT翻倍
直接JOIN两个未聚合的明细表，再GROUP BY和COUNT(*)，会因1:N关系引发笛卡尔膨胀。比如订单表某天有5条记录，用户表同一天有3条，INNER JOIN后那天就变成15行，COUNT(*)自然变成15而不是5或3。
实操建议：
- 所有统计必须在
JOIN前完成：(SELECT date, COUNT(*) AS order_cnt FROM orders GROUP BY date)和(SELECT date, COUNT(*) AS user_cnt FROM users GROUP BY date) - 每个子查询只返回唯一键（如
date）+ 聚合值，避免后续连接引入重复行 - 别写
SELECT *, COUNT(*) FROM orders o JOIN users u ON ... GROUP BY ...——这几乎必错
MySQL不支持FULL OUTER JOIN，强行用INNER JOIN拼接会漏边
想合并两个独立维度（比如“有订单的日期”和“有注册用户的日期”），需要保全两边都存在的日期，以及各自独有的日期。MySQL不支持FULL OUTER JOIN，若误用INNER JOIN，只会保留交集；若只用LEFT JOIN，则右表独有的日期仍丢失。
实操建议：
- 用
UNION拼接两个LEFT JOIN：(SELECT a.date, a.order_cnt, b.user_cnt FROM orders_agg a LEFT JOIN users_agg b ON a.date = b.date) UNION (SELECT b.date, a.order_cnt, b.user_cnt FROM orders_agg a RIGHT JOIN users_agg b ON a.date = b.date) - 确保两侧
SELECT列数、类型、顺序完全一致，缺失字段补NULL - 用
UNION而非UNION ALL，避免交集行重复计算两次
COALESCE没用对，加减运算结果变NULL
用LEFT JOIN后，某侧无数据时对应字段为NULL。如果直接做order_cnt - user_cnt，只要任一侧为NULL，整个表达式就是NULL，不是0。
实操建议：
- 所有参与算术运算的聚合字段必须用
COALESCE兜底：COALESCE(a.order_cnt, 0) - COALESCE(b.user_cnt, 0) -
COALESCE要包裹在最外层，别只包单个字段然后在外面加减 - 注意
NULL参与比较永远返回UNKNOWN，所以WHERE order_cnt > 0会漏掉order_cnt为NULL的行——该用WHERE order_cnt IS NOT NULL
真正容易被忽略的不是JOIN类型本身，而是ON和WHERE的分工边界，以及聚合动作发生的时机。哪怕表结构、索引、数据都完美，一个条件位置放错，或一次GROUP BY漏掉，就足以让报表少掉一半数据。
