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——这两个点不显眼，但一出错，整个统计就全盘失准。
