多对多JOIN导致SUM/COUNT翻倍是因行数乘积膨胀，唯一解法是预聚合右表再JOIN；需先验证膨胀存在，再用子查询按关联键GROUP BY压缩，配合COALESCE处理NULL。
多对多 JOIN 导致的 SUM 或 COUNT 翻倍，不是 SQL 写错了，而是数据库忠实地执行了关系代数——1 行主表 × N 行右表 × M 行另一右表 = N×M 行结果，聚合自然被放大。唯一靠谱解法是把“多”端提前压缩成“一”端，再 JOIN。
先确认是不是真的一对多/多对多膨胀
别急着改 SQL，先验证问题是否存在：
- 单独查左表行数：
SELECT COUNT(*) FROM users - 加一层 LEFT JOIN 后查最大匹配数：
SELECT user_id, COUNT(order_id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id ORDER BY COUNT(order_id) DESC LIMIT 5—— 如果某user_id对应几十个order_id，就坐实了膨胀 - 检查右表关联字段是否真唯一：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 1，有结果即说明一对多存在 - 看执行计划里的
rows_examined：如果远超左表总行数（比如 users 表 10 万行，却扫描 300 万行），基本就是多对多撑开的
用子查询预聚合切断膨胀链（最通用）
核心动作：让每个右表先按关联键（如 user_id、order_id）各自 GROUP BY 出一行，再和主表拼接。这样主表每行只连 1 行聚合值，SUM 不会重复累加。
- 子查询必须带别名，否则 MySQL 报
Error Code: 1248；别名不能是保留字，比如别写AS order - GROUP BY 字段必须和外层 JOIN 条件完全一致：子查询
GROUP BY order_id，外层就得ON o.id = t.order_id，不能错写成ON o.id = t.id - 过滤条件（如
status = 'paid'）必须写在子查询内部，写在外层 WHERE 里会让 LEFT JOIN 退化成 INNER JOIN - 记得用
COALESCE(SUM(...), 0)，否则未匹配时聚合字段为NULL，前端或报表可能出错
示例（统计每个用户订单总额 + 订单数）：
SELECT u.id, u.name,
COALESCE(t.total_amount, 0) AS total_amount,
COALESCE(t.order_count, 0) AS order_count
FROM users u
LEFT JOIN (
SELECT user_id,
SUM(amount) AS total_amount,
COUNT(*) AS order_count
FROM orders
WHERE status = 'paid'
GROUP BY user_id
) AS t ON u.id = t.user_id;
需要明细字段时换窗口函数（不增行）
当你既要展示“每个订单的最新支付时间”，又不想让 payments 表把 orders 撑开，窗口函数比 JOIN 更干净——它不改变行数，只在现有行上广播计算结果。
-
SUM(amount) OVER (PARTITION BY order_id)可直接算出每行所属订单的总金额，无需 JOIN - 若还需取最新一条支付记录，用
ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY paid_at DESC)配合WHERE rn = 1（CTE 或子查询中） - 注意：
SUM() OVER返回的是每行的副本值，不是压缩后的单行结果；真要输出“每个订单一行”，仍得回退到预聚合子查询 - MySQL 5.7 不支持窗口函数，得用相关子查询或升级到 8.0+
多个一对多表嵌套时别硬 JOIN
订单 → 订单项 → 库存记录，两层一对多叠加，行数是乘积级爆炸（1×3×5=15 行）。这时候强行 JOIN 再 GROUP BY 主表，性能差且逻辑难维护。
- 优先拆成独立预聚合子查询：
(SELECT order_id, SUM(qty) FROM items GROUP BY order_id) i和(SELECT order_id, MAX(stock_time) FROM stock_log GROUP BY order_id) s，再分别 LEFT JOIN - 如果业务允许，用 JSON 打包明细（MySQL 5.7+/PostgreSQL）：
JSON_AGG(JSON_OBJECT('item_id', item_id, 'price', price))，把多行压成一个字段，避免膨胀 - 警惕隐式 JOIN：
FROM a, b WHERE a.id = b.a_id和显式JOIN行为一致，但更难排查膨胀源
真正容易被忽略的，是预聚合子查询里漏掉 GROUP BY，或者 JOIN 键类型不一致（比如一边是 BIGINT，一边是 VARCHAR），导致索引失效、全表扫描——这些细节不报错，但会让翻倍问题从“逻辑错误”变成“性能灾难”。
