JOIN后聚合结果重复是执行顺序导致的必然现象：先JOIN生成膨胀行集，再SUM/COUNT累加重复行；修复须用子查询预聚合（如按order_id分组压缩明细表）或窗口函数（如SUM() OVER），而非修改聚合函数参数。
JOIN后聚合结果重复，不是SQL写错了，是执行顺序决定的必然现象：先JOIN生成膨胀行集，再聚合——SUM、COUNT自然在重复行上累加。修复必须切断“主表一行变多行”的链条，不能靠改函数参数硬凑。
为什么COUNT/SUM在JOIN后会虚高
数据库执行顺序是 FROM → JOIN → WHERE → GROUP BY → SELECT。哪怕你只写 COUNT(o.order_id)，系统也得先把 orders 和 order_items 全部JOIN出来：一个订单匹配3条明细，订单字段就复制3次，COUNT(*) 算出的就是3，不是1。
- 典型表现：总金额或计数是预期值的整数倍（2倍、3倍），且倍数 ≈ 关联表中该主键的平均匹配行数
-
COUNT(DISTINCT o.order_id)可修正计数，但SUM(DISTINCT amount)完全无效——它去重的是数值本身，不是行 - 执行计划里
rows_examined远大于左表行数，基本可确认是JOIN膨胀
用子查询预聚合切断膨胀链
核心动作是让明细表先按业务主键压缩成一行，再和主表关联。这样每行主表只对应1行聚合值，SUM()、COUNT() 不再有重复行可加。
- 子查询必须
GROUP BY明细表的外键（如order_id、user_id），漏掉这步等于白做 - JOIN条件字段必须和子查询
GROUP BY字段严格一致，类型也要匹配（比如都是INT，避免VARCHAR隐式转换） - 用
LEFT JOIN时，记得用COALESCE(ord.total_amount, 0)处理NULL，否则没明细的订单会显示NULL而非0
SELECT o.id, o.order_date, COALESCE(i.total_price, 0) AS total_price FROM orders o LEFT JOIN ( SELECT order_id, SUM(price) AS total_price FROM order_items GROUP BY order_id ) i ON o.id = i.order_id;
用窗口函数替代JOIN获取汇总值
当你需要同时返回明细行和汇总值（比如每行显示“本订单总金额”），SUM() OVER (PARTITION BY order_id) 比传统JOIN更干净——它不改变行数，只把聚合值广播到每行。
-
PARTITION BY字段必须是主表唯一标识（如order_id），否则仍会算错 - 不能用它聚合右表字段（如
COUNT(DISTINCT oi.product_id) OVER），因为窗口函数无法自动去重已膨胀的行 - MySQL 5.7 及更早版本不支持
OVER，必须降级为相关子查询或预聚合
SELECT oi.order_id, oi.price,
SUM(oi.price) OVER (PARTITION BY oi.order_id) AS order_total
FROM order_items oi;
GROUP BY字段必须覆盖语义主键
如果你JOIN了三张表，又希望按用户维度统计，但 SELECT 里还带了 order_status 或 addr_type，GROUP BY 就不能只写 user_id：
- 写
GROUP BY user_id, order_status→ 实际是按“用户+订单状态”分组，每组统计的是该状态下的订单数，不是用户总数 - 写
GROUP BY user_id却SELECT order_status→ 在 strict 模式下直接报错：Expression #2 not in GROUP BY - 如果真要带
order_status，要么加进GROUP BY，要么用聚合函数包裹，比如MAX(order_status)或STRING_AGG(DISTINCT order_status, ',')
真正容易被忽略的点是：重复不是发生在 GROUP BY 阶段，而是在 JOIN 阶段就已注定。看到 COUNT 虚高，第一反应不该是调聚合函数，而是检查JOIN是否已把数据撑开。
