SQL多表JOIN导致数据翻倍是因一对多关系生成重复物理行，聚合函数据此计算失真；需检查右表关联字段是否唯一、过滤条件应放ON而非WHERE、禁用DISTINCT治标不治本，预聚合才是根治方案。

SQL多表JOIN导致数据翻倍，不是数据库出错，而是JOIN阶段已生成重复物理行——聚合函数（如SUM、COUNT）只是老老实实按这些行算，结果自然失真。

先确认是不是一对多关系在捣鬼

翻倍最常见原因是右表对左表主键不唯一。比如用user_id连接订单表和用户表，但订单表里一个user_id出现5次，LEFT JOIN后该用户行就被复制5次。

• 执行SELECT join_column, COUNT(*) FROM right_table GROUP BY join_column HAVING COUNT(*) > 1，看是否有重复值
• 若右表是视图或子查询，把它单独拿出来跑一遍，检查输出里join_column是否已重复
• 用SHOW CREATE TABLE right_table确认字段有没有UNIQUE或PRIMARY KEY约束
• 执行计划中rows_examined远大于左表总行数，就是强信号

WHERE和ON写错位置，会让问题更难察觉

LEFT JOIN后对右表字段加WHERE过滤（如WHERE o.status = 'paid'），会导致未匹配或状态不符的左表行被整体剔除——LEFT JOIN退化成INNER JOIN，你以为“数据变少了”，其实是“翻倍被掩盖了”。

• 正确做法是把过滤条件塞进ON：例如LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'
• 放在ON里，右表只拉符合条件的行进来，从源头控量；放在WHERE里，优化器先完成全量JOIN再筛，膨胀早已发生
• 如果业务要求保留无匹配记录的左表行，又只取右表部分数据，WHERE绝对不能碰右表字段

别用DISTINCT硬压，它解决不了SUM翻倍

DISTINCT只能去重最终结果行，对SUM类聚合完全无效：SUM(DISTINCT amount)是去重金额值，不是去重行；而且DISTINCT *可能把本该区分的合法组合（如同一用户两笔同金额订单）也合并掉。

• DISTINCT无法修复已发生的JOIN膨胀，只是把错误结果“压平”
• 大表上DISTINCT常触发临时表+文件排序，性能损耗明显
• 上线前必须验证DISTINCT前后关键指标是否一致，否则可能掩盖真实数据异常

预聚合才是根治方案，但细节一漏就全错

把多端表先按关联键压缩成一行，再JOIN主表，才能确保每行主表只对应1行聚合值。这是唯一能真正切断行复制的解法。

• 子查询必须严格GROUP BY明细表的外键（如order_id），漏了等于白做
• 外层JOIN条件必须和子查询GROUP BY字段完全一致，比如子查询按user_id分组，外层就得ON u.id = s.user_id
• LEFT JOIN未匹配时，聚合字段为NULL，SUM(NULL)返回NULL而非0，得显式写COALESCE(SUM(), 0)
• 子查询里必须内置业务过滤（如WHERE status != 'cancelled'），否则聚合基数仍偏大

最容易被忽略的是：预聚合子查询的GROUP BY字段和外层JOIN条件没对齐，或者忘了COALESCE处理NULL——这两个点不显眼，但一出错，整个统计就全盘失准。