多表关联后GROUP BY数据翻倍是因JOIN阶段行数膨胀所致；应检查右表关联字段是否唯一、用预聚合子查询替代宽表JOIN、过滤条件须置于ON中而非WHERE，并根据业务逻辑选用COUNT(DISTINCT)或预聚合。
多表关联后 GROUP BY 出现数据翻倍，不是 GROUP BY 本身错了，而是 JOIN 阶段已经把行数撑大了——聚合只是在错误的中间结果上“认真计算”，越算越错。
查右表关联字段是否真唯一
翻倍最常见原因是右表（被 JOIN 的表）里关联字段存在重复值，比如 orders.user_id 有 5 条记录对应同一个用户，LEFT JOIN users 就会让该用户行被复制 5 次。
- 直接执行：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 1，看有没有“一对多” - 对比关键数字：
COUNT(*)vsCOUNT(DISTINCT user_id)，若前者远大于后者，基本锁定是 JOIN 膨胀 - 检查约束：
SHOW CREATE TABLE orders，确认user_id是否加了FOREIGN KEY或业务上应有UNIQUE却没建 - 视图或子查询？把它单独跑一遍，看输出里
user_id是否已重复——问题可能藏在中间层
用预聚合子查询代替宽表 JOIN
不靠 DISTINCT 硬压，而是从源头控制行数：让右表先按关联键压缩成一行，再和主表拼接。
- 子查询必须
GROUP BY关联字段，且外层ON字段要完全一致，例如子查询GROUP BY order_id，外层就得写ON o.id = sub.order_id - 过滤条件（如
status = 'paid'）必须写在子查询内部，不能挪到外层WHERE，否则无效行仍参与聚合 - 注意
NULL：LEFT JOIN 未匹配时，子查询字段为NULL，SUM(amount)返回NULL，需用COALESCE(SUM(amount), 0)
示例：SELECT u.id, u.name, COALESCE(t.total_amount, 0) FROM users u LEFT JOIN (SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status = 'paid' GROUP BY user_id) t ON u.id = t.user_id
COUNT 和 SUM 失真时怎么修
GROUP BY 后直接用 COUNT(*) 或 SUM()，本质是在膨胀后的物理行上算，不是按业务逻辑行。修复要看你想统计什么：
- 统计“有多少个订单”：用
COUNT(DISTINCT o.order_id)，不是COUNT(*) - 统计“每个用户的订单总金额”：别在 JOIN 后直接
SUM(o.amount)，而应先对orders表按user_id聚合，再 JOIN - LEFT JOIN 中，
COUNT(o.order_id)会忽略NULL（即无订单用户不计数），COUNT(*)却把空行也算进去——语义完全不同，选错就全错
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' - 优化器会在 JOIN 前就筛掉右表无效行，避免中间结果膨胀
- 如果业务要求保留无订单用户，又只取已支付订单，
WHERE碰右表字段就是致命错误
真正难处理的，是那种“业务上本该唯一，但历史脏数据导致重复”的情况——它不会报错，EXPLAIN 看起来也正常，只有核对业务口径时才会发现总数对不上。这时候光改 SQL 不够，得推动清理数据或补约束。
