JOIN时NULL值导致统计丢失，应改用LEFT JOIN或UNION ALL模拟FULL OUTER JOIN保全数据，并确保所有聚合在JOIN前完成、用COALESCE处理NULL。
JOIN 时 NULL 值导致统计结果丢失怎么办
直接 INNER JOIN 会丢掉任一侧没有匹配的记录，比如某天在订单表里有数据，但用户表里没对应用户（或反之），当天的统计就彻底消失。实际做跨源聚合时，更常见的是用 LEFT JOIN 或 FULL OUTER JOIN 保全各侧原始计数。
关键点在于：JOIN 本身不聚合，它只是把行“拉平”；统计必须在 JOIN 后用 GROUP BY 或窗口函数重算。别指望 JOIN 自动帮你 sum() 两表的 count 字段。
- 若主表是日期维度表（含全量日期），用
LEFT JOIN关联订单汇总、用户注册汇总等子查询，能保证日期对齐 - MySQL 不支持
FULL OUTER JOIN，得用UNION ALL拼两个LEFT JOIN模拟 - JOIN 前先各自
GROUP BY聚合（如按日期统计订单数、按日期统计新用户数），再 JOIN，避免笛卡尔积膨胀
多源 COUNT 结果 JOIN 后重复计算怎么破
这是最常踩的坑：A 表按日期分组有 10 行，B 表同一天有 3 行，INNER JOIN 后那天就变成 30 行，再 SUM() 就翻倍了。根本原因在于 JOIN 引入了 1:N 关系，而 COUNT 是行级计数。
正确做法是——所有统计必须在 JOIN 前完成，且每个子查询只返回唯一键（如 date）+ 聚合值：
SELECT COALESCE(a.date, b.date) AS date, COALESCE(a.order_cnt, 0) AS order_cnt, COALESCE(b.user_cnt, 0) AS user_cnt FROM (SELECT date, COUNT(*) AS order_cnt FROM orders GROUP BY date) a FULL OUTER JOIN (SELECT date, COUNT(*) AS user_cnt FROM users GROUP BY date) b ON a.date = b.date
- 绝不要写
SELECT *, COUNT(*) FROM orders o JOIN users u ON ... GROUP BY ...—— 这几乎必错 -
COALESCE处理某侧无数据时的 NULL，否则加减运算会变 NULL - PostgreSQL/SQL Server 支持
FULL OUTER JOIN，MySQL 用户得用(A LEFT JOIN B) UNION ALL (B LEFT JOIN A WHERE A.key IS NULL)
不同时间粒度（日 vs 周）的统计怎么对齐
订单按天统计，用户注册却只存了周报表？硬 JOIN 会因粒度不一致导致多对一错配。不能靠数据库自动“理解”业务语义。
必须显式统一时间维度：要么把周汇总拆成每日均值（仅适用于均匀分布假设），要么把日数据向上归约到周：
- 用
DATE_TRUNC('week', date)（PostgreSQL）、YEARWEEK(date)（MySQL）或CONVERT(VARCHAR(6), date, 112)（SQL Server）生成周键 - 确保两个子查询都用同一套截断逻辑生成分组键，再 JOIN
- 如果一方是小时级、另一方是月级，优先降维到低频粒度（如都转成年月），避免信息失真
JOIN 大宽表导致性能崩了怎么调
当订单汇总、用户属性、地域标签等十几张统计表全 JOIN 到一张日期主表上，执行计划容易退化成嵌套循环，内存爆掉或跑几十分钟。
核心思路是减少中间结果集大小：
- 每张子查询务必带
WHERE过滤（如限定最近 90 天），别让 JOIN 扫全表 - 用 CTE（
WITH）替代子查询，部分引擎能更好优化；但注意 PostgreSQL 中 CTE 默认物化，可能反而更慢 - 检查 JOIN 键是否有索引——即使是对
GROUP BY后的临时结果，也要确保date或week_id列在物化视图/临时表上有索引 - 实在卡死，拆成两步：先 JOIN 两张关键表产出中间表，再逐步 LEFT JOIN 其余维度
跨源统计不是拼积木，是搭脚手架——每根杆的位置、承重、连接方式都得单独验算。最容易被忽略的，是默认认为“JOIN 之后再 GROUP BY 就万事大吉”，其实那一步往往已经晚了。
