多表JOIN后GROUP BY虚高源于JOIN阶段数据膨胀，需用预聚合避免；GROUP BY字段须带表前缀且非聚合字段必须显式列出；LEFT JOIN中COUNT(*)恒为1，统计关联数应使用COUNT(右表非空字段)；时间等过滤条件若需保留左表空记录，必须写在ON而非WHERE。
多表 JOIN 后 GROUP BY 不能直接套用单表逻辑，核心问题不是“怎么写 GROUP BY”，而是“JOIN 已经把数据撑开了”——你看到的 COUNT 或 SUM 虚高，是 JOIN 阶段就注定的，不是 GROUP BY 没写对。
GROUP BY 字段必须带表前缀，且全部来自主表
多表有同名列（比如 id、name）时，GROUP BY id 是非法的。数据库无法判断你要按哪张表分组，MySQL 8.0+ 和 PostgreSQL 直接报错，低版本可能随机取值。
- 正确写法：
GROUP BY u.id, u.name（假设u是主表别名） - 错误写法：
GROUP BY id、GROUP BY users.id（别名未定义）、GROUP BY u.name AS username（别名不能用于 GROUP BY） -
SELECT中所有非聚合字段（如u.name）必须显式出现在GROUP BY中，否则ONLY_FULL_GROUP_BY模式下直接拒绝执行
LEFT JOIN 后 COUNT(*) 为什么总是 1？
COUNT(*) 统计的是结果集行数，而 LEFT JOIN 保证左表每行至少出现一次——哪怕右表没匹配，这行也存在，COUNT(*) 就是 1。这不是 bug，是语义误解。
- 要统计“每个用户下了几单”，必须用
COUNT(o.id)或COUNT(o.created_at)（前提是该字段定义为NOT NULL） - 想让无订单用户显示为 0，写成
COALESCE(COUNT(o.id), 0) - 别用
COUNT(1)替代——它和COUNT(*)在LEFT JOIN下行为一致，但掩盖真实逻辑 - 如果右表字段允许 NULL（比如
o.status），COUNT(o.status)会漏掉 status 为 NULL 的有效记录，不可靠
一对多 JOIN 导致 SUM/COUNT 虚高怎么办？
1 行用户关联 3 行订单 + 2 行地址 → JOIN 后变成 6 行，GROUP BY u.id 再 SUM(o.amount) 就会把同一笔订单加 2 次（因地址重复）。
- 根本解法是预聚合：先对明细表按外键汇总，再 JOIN 主表
- 错误写法：
FROM users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN addresses a ON u.id = a.user_id GROUP BY u.id - 正确写法：子查询先聚合订单和地址，例如
(SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id)和(SELECT user_id, COUNT(*) AS addr_cnt FROM addresses GROUP BY user_id)，再分别 LEFT JOIN 到users - 预聚合后中间结果集大幅缩小，性能通常提升一个数量级，且避免笛卡尔积干扰业务语义
WHERE 条件写在 ON 还是 WHERE？对 LEFT JOIN 结果影响巨大
写在 WHERE 是关联完再过滤整行；写在 ON 是关联时过滤右表。这对保留左表空记录至关重要。
- 查“2024 年下单的用户及订单数”，业务要包含没在 2024 年下单的用户（订单数为 0）→ 时间条件必须写进
ON：LEFT JOIN orders o ON u.id = o.user_id AND o.created_at >= '2024-01-01' - 若写成
WHERE o.created_at >= '2024-01-01'，没在 2024 年下单的用户直接被踢出结果 - 性能上，
ON过滤更早，JOIN 输入更小；WHERE过滤晚，中间数据量更大
最容易被忽略的点是：重复不是发生在 GROUP BY 阶段，而是在 JOIN 阶段就已注定。看到 COUNT 或 SUM 异常，第一反应不该是调 GROUP BY，而是回溯 JOIN 后的结果集——用 SELECT * 看几行，比对着文档改语法更快定位问题。
