sum()结果偏大主要是因多对多join引发隐式笛卡尔积，导致明细行重复膨胀；需用count(*)与count(distinct主键)比对确认，修复应优先子查询预聚合或窗口函数。
为什么 SUM() 结果比预期大？先看是不是多对多关联在捣鬼
直接结论：SUM() 偏大，90% 以上是因为 JOIN 引入了隐式笛卡尔积——尤其是主表与从表存在多对多关系时，一行变多行，聚合前数据已膨胀。不是函数算错了，是它算的是“被重复展开后的行”。
怎么快速确认是不是多对多导致的翻倍？
别急着改 SQL，先用子查询或 COUNT(*) 检查中间结果集大小：
- 把 JOIN 后的临时结果单独查出来，加
SELECT COUNT(*)和SELECT COUNT(DISTINCT 主键)对比——如果前者远大于后者，说明有重复 - 例如：订单表
orders关联订单明细order_items（一对多）再关联商品分类categories（一对一），没问题；但如果还关联了订单标签order_tags（一个订单多个标签），而你没去重或聚合，order_tags就会把每条订单行复制 N 次 - 典型错误写法：
SELECT o.id, SUM(oi.amount) FROM orders o JOIN order_items oi ON o.id = oi.order_id JOIN order_tags ot ON o.id = ot.order_id GROUP BY o.id—— 这里ot的每一条都会让oi行重复一次
修复方案：按场景选最稳妥的写法
核心原则：聚合操作尽量靠近原始明细表，避免在 JOIN 后再 SUM()；多对多维度必须提前收拢。
- 用子查询预聚合：先把
order_items按订单汇总好，再 JOIN 其他维度，例如：(SELECT order_id, SUM(amount) AS total FROM order_items GROUP BY order_id) oi - 用
LATERAL（PostgreSQL）或APPLY（SQL Server）做关联聚合，避免主表膨胀 - MySQL 8.0+ 可用窗口函数绕过 JOIN：
SUM(oi.amount) OVER (PARTITION BY oi.order_id)配合去重主表 - 如果必须 JOIN 多对多表（如要取标签名列表），改用
STRING_AGG()或GROUP_CONCAT()聚合该维度，而不是让它参与数值聚合的层级
容易被忽略的坑：JOIN 顺序和 NULL 也会影响 SUM()
SUM() 本身忽略 NULL，但 JOIN 条件写错可能导致本该关联上的行变成 NULL，进而让分组变少、单组值变大；更隐蔽的是 LEFT JOIN 后没加 WHERE 过滤，把外连接的 NULL 行也纳入了分组统计范围。
- 检查所有 JOIN 条件是否用了正确的关联字段，特别是复合键漏字段
- LEFT JOIN 后如果对右表字段加了
WHERE right_table.id IS NOT NULL，实际等价于 INNER JOIN，但很多人忘了这点，误以为还是左连接语义 - 用
EXPLAIN看执行计划，重点关注 rows 列——如果某次 JOIN 输出行数远超左表，基本就是翻倍源头
