根本原因是JOIN导致行数膨胀，GROUP BY在膨胀后的结果上统计，使COUNT(*)虚高；需用COUNT(DISTINCT字段)去重或先聚合再关联。
GROUP BY 多表 JOIN 后统计变多，根本原因是什么
不是 GROUP BY 本身出错，而是 JOIN 把 1 行扩成了 N 行，再 GROUP BY 只是“在膨胀后的结果上分组”，自然导致 COUNT(*) 虚高。比如用户表 users 1 行关联订单表 orders 3 行，JOIN 后就变成 3 行；此时 GROUP BY user_id 得到的 COUNT(*) 是 3，但你想统计的是“该用户下了几个订单”，这反而是对的；可如果想统计“该用户有几个收货地址”，而地址表 addresses 有 2 行，JOIN 之后就变成 3 × 2 = 6 行，COUNT(*) 就会错成 6。
用 COUNT(DISTINCT column) 修正关联重复计数
当需要统计被 JOIN 放大过的维度（如订单数、地址数、标签数）时，必须用 COUNT(DISTINCT ...) 显式去重：
-
COUNT(DISTINCT o.order_id)→ 正确统计每个用户的订单数量，哪怕订单和地址做了笛卡尔积 -
COUNT(DISTINCT a.addr_id)→ 正确统计每个用户的地址数，不因订单行数干扰 - 不能写
COUNT(DISTINCT *)—— 语法错误；必须指定具体字段，且该字段需来自被 JOIN 的表并能唯一标识业务实体 - 注意 NULL：如果
addr_id允许为 NULL，COUNT(DISTINCT addr_id)会自动忽略它；若需包含空值逻辑，得先用COALESCE(addr_id, -1)转换
避免 JOIN 膨胀：用子查询或聚合先行代替宽表 JOIN
比起把所有表一次性 JOIN 起来再 GROUP BY，更稳的方式是“先各自聚合，再关联”：
- 先查每个用户的订单总数：
(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 —— 中间无行数爆炸风险 - 优势：逻辑清晰、执行计划可控、避免 MySQL 的
only_full_group_by报错（尤其在 SELECT 多个非分组字段时） - 缺点：子查询可能无法利用外层 WHERE 条件下推，大数据量时注意加索引，比如
orders(user_id)
GROUP BY 字段必须覆盖所有 JOIN 后的“语义主键”
如果你 JOIN 了三张表，又希望按用户维度统计，但 SELECT 里还带了 order_status 或 addr_type，GROUP BY 就不能只写 user_id：
- 写
GROUP BY user_id, order_status→ 实际是按“用户+订单状态”分组，每组统计的是该状态下的订单数，不是用户总数 - 写
GROUP BY user_id却 SELECTorder_status→ 在 strict 模式下直接报错：Expression #2 of SELECT list is not in GROUP BY clause - 真要保留
order_status又只按用户分组？只能用聚合函数包裹，例如MAX(order_status)或ANY_VALUE(order_status)（MySQL），但语义已丢失——你不再知道哪条订单的状态被取出来了 - 所以关键判断点是：这个字段是“分组维度”，还是“被统计的指标”，还是“仅作展示的附属信息”？三者混在一起，GROUP BY 就容易失控
SELECT * 不加 GROUP BY，LIMIT 10 看原始 JOIN 结果，比反复调 GROUP BY 更快定位根因。 
