count虚高源于join导致行数膨胀，而非group by错误；应使用count(distinct column)去重，或先对各表分别聚合再join，以避免笛卡尔积干扰统计结果。
COUNT虚高不是GROUP BY写错了，是JOIN先把1行撑成了N行——比如用户表1行关联订单表3行、地址表2行，JOIN后就是6行；COUNT(*)在6行上算，结果自然变成6。你要统计“该用户有几个订单”，答案应是3，但直接COUNT(*)给你报6。
用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路径是否引入了隐式笛卡尔积——尤其是多对一未加约束、或一对多表缺少唯一索引时。
