count/sum虚高源于join阶段行数膨胀而非group by错误：用户表1行关联订单表3行、地址表2行后变为6行，count(*)在膨胀后的6行上统计得6；应改用count(distinct o.order_id)去重，或先聚合再join以避免笛卡尔积。
为什么 COUNT/SUM 在 JOIN 后虚高？
不是 GROUP BY 写错了，而是 JOIN 先把 1 行撑成了 N 行——比如用户表 1 行关联订单表 3 行、地址表 2 行，JOIN 后就是 6 行；GROUP BY user_id 是在这 6 行上分组，COUNT(*) 自然变成 6。
此时你要统计“该用户有几个地址”，答案应该是 2，但直接 COUNT(*) 给你报 6。问题根源在 JOIN 阶段就已注定，不是分组逻辑的问题。
- 检查执行计划中
rows列：JOIN 后的行数是否远超预期 - 用
SELECT *+GROUP BY前加 LIMIT 10，肉眼观察重复膨胀（如一个 user_id 出现 6 次） - 禁用所有 JOIN，只保留主表 + GROUP BY，对比 COUNT 值是否回归合理范围
COUNT(DISTINCT column) 什么时候能用？
当目标是统计被 JOIN 放大的维度（如订单数、地址数、标签数），必须显式去重：
-
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 所有表再 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表——中间无行数爆炸风险 - 优势：逻辑清晰、执行计划可控、避免 MySQL 的
only_full_group_by报错（尤其在 SELECT 多个非分组字段时） - 缺点：子查询可能无法利用外层
WHERE条件下推；大数据量时注意给orders(user_id)等字段加索引
GROUP BY 字段漏写会导致什么？
如果你 JOIN 了三张表，又希望按用户维度统计，但 SELECT 里还带了 order_status 或 addr_type，GROUP BY 就不能只写 user_id：
- 写
GROUP BY user_id, order_status→ 实际是按“用户+订单状态”分组，每组统计的是该状态下的订单数，不是用户总数 - 写
GROUP BY user_id却SELECT order_status→ 在 strict 模式下直接报错：Expression #2 not in GROUP BY - 如果真要带
order_status，要么把它加进GROUP BY，要么用聚合函数包裹，比如MAX(order_status)或STRING_AGG(DISTINCT order_status, ',')
真正容易被忽略的点是：重复不是发生在 GROUP BY 阶段，而是在 JOIN 阶段就已注定。看到 COUNT 虚高，第一反应不该是调 GROUP BY，而是回溯 JOIN 结果集——用 SELECT * 看一眼实际返回了多少行。
