SQL聚合数据虚增是因一对多JOIN导致物理行复制，确认方法：查右表关联字段重复、对比COUNT(*)与COUNT(DISTINCT左表主键)、看EXPLAIN中rows是否异常放大。
JOIN后聚合数据虚增不是SQL算错了，是它严格按物理行数执行——只要右表对左表主键存在一对多关系，1行主表就会被复制N次，SUM、COUNT就在这些重复行上累加N遍。
怎么快速确认是不是一对多导致的虚增
别急着改SQL，先用三句话定位问题根源：
- 查右表关联字段是否重复：
SELECT join_column, COUNT(*) FROM right_table GROUP BY join_column HAVING COUNT(*) > 1—— 有结果就坐实了一对多 - 对比两个计数：
COUNT(*)和COUNT(DISTINCT left_table.primary_key)，前者显著更大，说明中间结果已膨胀 - 看执行计划：
EXPLAIN中rows列若比左表原始行数高几倍甚至几十倍（比如订单表1万行，JOIN后预估42万行），就是强信号
LEFT JOIN里WHERE和ON写错位置会掩盖真实问题
这不是语义差别，是执行逻辑的根本区别：放WHERE是全量JOIN完再筛，膨胀已经发生；放ON是从源头控制右表参与连接的行数。
- 错误写法：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'→ 先拉所有订单，再过滤，中间已复制多次 - 正确写法：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'→ 右表只取已支付的行，没膨胀 - 如果业务要求保留无订单用户，又只统计已支付订单，
WHERE里绝对不能碰右表字段，否则LEFT JOIN退化成INNER JOIN
子查询预聚合必须做对这三件事
这是唯一能根治虚增的解法，但漏一个细节结果就错：
-
GROUP BY字段必须和外层ON条件里的右表字段完全一致，比如子查询按order_id分组，外层就得写ON o.id = oi.order_id，不能写成ON o.id = oi.id - 过滤条件（如
status = 'paid'）必须写在子查询内部，不能挪到外层WHERE，否则子查询输出仍含无效行 -
LEFT JOIN未匹配时，聚合字段为NULL，SUM(NULL)返回NULL而非0，得用COALESCE(SUM(), 0)显式处理
窗口函数SUM() OVER能绕过膨胀但有硬限制
它不改变行数，靠PARTITION BY在逻辑分组内独立求和，适合需要每行都显示汇总值的场景（比如明细行旁显示“本订单总金额”）：
- 适用：
SELECT oi.order_id, oi.price, SUM(oi.price) OVER (PARTITION BY oi.order_id) AS order_total FROM order_items oi - 不适用：你要输出的是“每个用户的订单总额”，而不是明细行——这时仍需先聚合再
JOIN，否则OVER无法替代GROUP BY - 注意：老版本MySQL（OVER无法解决最终结果集维度压缩问题
真正容易被忽略的是：问题不在SUM函数本身，而在JOIN引入的隐式重复。盯着聚合函数调参数不如先看EXPLAIN里rows有没有突增——那是数据库在悄悄告诉你：“我已复制了这么多行”。
