GROUP BY统计变多不是其本身问题，而是多表JOIN导致行数膨胀，使COUNT(*)虚高；应使用COUNT(DISTINCT字段)或先聚合再JOIN来准确计数。
GROUP BY 统计变多，根本不是 GROUP BY 的错
多表 JOIN 后 COUNT(*) 虚高，本质是行数膨胀：1 个用户关联 3 条订单 + 2 个地址 → JOIN 后变成 6 行。此时 GROUP BY user_id 是在 6 行上分组，COUNT(*) 自然得 6，但你要的可能是“该用户有 3 个订单、2 个地址”——这两个数字都被放大干扰了。
常见错误现象：
- 写
SELECT user_id, COUNT(*) FROM users u JOIN orders o ON u.id = o.user_id JOIN addresses a ON u.id = a.user_id GROUP BY user_id，结果订单数和地址数全乱套 - 加了
DISTINCT却写成COUNT(DISTINCT *)，直接语法报错
COUNT(DISTINCT 字段) 是最直接的修正手段
只要字段能唯一标识业务实体（比如 order_id、addr_id），就用它去重计数。这是语义最清晰、兼容性最好的方案。
使用场景：
-
COUNT(DISTINCT o.order_id)→ 统计每个用户的订单数量，不受地址行数影响 -
COUNT(DISTINCT a.addr_id)→ 统计每个用户的地址数量，不受订单行数干扰 - 若字段允许 NULL，
COUNT(DISTINCT addr_id)会自动跳过；需保留空值逻辑时，改用COUNT(DISTINCT COALESCE(addr_id, -1))
注意：order_id 必须来自被 JOIN 的表，且在该表中具有业务唯一性；不能用 id 这类主键跨表混用，否则去重失效。
先聚合再 JOIN，比宽表 JOIN 更稳
当关联表多、数据量大，或需要多个维度统计（如同时要订单数、地址数、标签数）时，“先各自聚合，再 LEFT JOIN”可彻底规避行数爆炸。
实操建议：
- 订单聚合子查询：
(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，再按需GROUP BY—— 中间无笛卡尔积风险 - 确保子查询字段上有索引，例如
orders(user_id)和addresses(user_id)
性能影响：子查询无法下推外层 WHERE 条件，大数据量时注意加过滤条件或物化中间结果。
别指望 GROUP BY 返回“某一行的完整原始记录”
想取每个用户最新一条订单的 order_id、amount、created_at？GROUP BY user_id 配 MAX(created_at) 只能拿到时间，拿不到对应那条记录的其他字段。
这时必须换思路：
- PostgreSQL / SQL Server / MySQL 8.0+：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)标号后过滤rn = 1 - 老版本 MySQL：用相关子查询或自连接，但性能差、易出错
- 绝对不要用
GROUP BY user_id, order_id, amount, created_at强行“绕开”——这根本不是去重，只是把分组粒度打碎了
容易忽略的点：窗口函数的 PARTITION BY 和 ORDER BY 必须严格匹配业务意图；没索引时，OVER (PARTITION BY user_id ORDER BY created_at DESC) 可能触发全表扫描。
