财务报表汇总金额翻倍不是数据库错误，而是JOIN导致物理行复制、SUM重复累加所致；必须用子查询对多端表按关联字段预聚合（如GROUP BY user_id）后再LEFT JOIN主表，并用COALESCE处理NULL。
财务报表汇总金额翻倍，不是数据库算错了，是 JOIN 后物理行被复制了，SUM() 必然重复累加——必须把多端表先“压成一行”，再拼主表。
怎么一眼确认是不是一对多导致的翻倍
别改 SQL，先查右表关联字段有没有重复：
-
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 1—— 如果返回结果不为空，说明一个user_id对应多条订单，这就是根源 - 对比两个数：
COUNT(*)（JOIN 后总行数）和COUNT(DISTINCT users.id)（实际用户数），前者远大于后者，基本锁定膨胀 - 看
EXPLAIN的rows_examined：如果扫描行数是左表的 3–5 倍，几乎可以确定是 JOIN 膨胀 - 右表如果是视图或子查询？把它单独执行一遍，检查输出里
user_id是否已重复
LEFT JOIN 后直接 SUM() 为什么一定错
JOIN 不是“贴数据”，是做逻辑展开：1 行用户 × 5 行订单 = 5 行结果。后续 SUM(orders.amount) 就真把同一笔订单金额加了 5 次。
-
COUNT(*)、SUM()、AVG()全部受影响，但错误不报错、日志无异常 -
DISTINCT救不了：SUM(DISTINCT amount)是去重金额值，不是去重行；COUNT(DISTINCT order_id)只对计数类有效，且掩盖聚合逻辑缺陷 - 盲目加
GROUP BY users.id没用——JOIN已经撑开数据，分组只是在错误的数据上再分
预聚合子查询写法及三个致命细节
核心动作：让订单表先按 user_id 聚合成每用户一行，再和用户表拼接。
- 子查询必须严格
GROUP BY user_id，漏掉就等于没做预聚合 - 外层
ON u.id = ord.user_id的字段名、类型必须和子查询GROUP BY字段完全一致（比如不能是ord.uid或隐式转字符串） -
LEFT JOIN未匹配时，ord.total_amount是NULL，SUM(NULL)返回NULL，不是0——必须写COALESCE(ord.total_amount, 0)
正确示例：
SELECT u.id, u.name, COALESCE(ord.total_amount, 0) AS total_amount FROM users u LEFT JOIN ( SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status = 'paid' -- 过滤必须放子查询里！ GROUP BY user_id ) ord ON u.id = ord.user_id;
什么时候不该用预聚合，而该换思路
如果业务上本就允许一对多（比如一个用户有多个角色、多个收货地址），那翻倍反而是正确反映事实——强行预聚合等于丢信息。
- 要展示明细字段（如最新订单时间、首笔付款金额），又不想膨胀，改用窗口函数：
SUM(amount) OVER (PARTITION BY order_id)或FIRST_VALUE(payment_time) OVER (PARTITION BY user_id ORDER BY created_at DESC) - 要同时聚合 + 展开多对多维度（比如每个订单对应多个标签），改用
STRING_AGG(tag_name)或JSON_AGG()把标签打包成一列，不参与数值聚合层级 - MySQL 5.7 或旧版 PostgreSQL 不支持窗口函数？只能退回到相关子查询，但性能更差，务必加索引
最容易被忽略的其实是子查询里的 WHERE 条件位置和 COALESCE 缺失——这两处一错，结果看着像对了，实则要么漏数据，要么前端报空值错误。
