跨表关联后COUNT(*)虚高是因为JOIN导致行数膨胀，必须用COUNT(DISTINCT字段)显式去重或子查询预聚合，二者择一；混用反而更易出错。
直接说结论：跨表关联后要避免重复聚合，不能靠 GROUP BY 本身“修正”，必须从数据膨胀源头控制——要么用 COUNT(DISTINCT) 显式去重，要么用子查询预聚合，二者选一，混用反而更易出错。
为什么 JOIN 后 COUNT(*) 总是虚高？
不是 GROUP BY 写错了，是 JOIN 先把行数撑大了。比如一个用户有 3 个订单、2 个地址，LEFT JOIN orders 和 LEFT JOIN addresses 会生成 3 × 2 = 6 行，COUNT(*) 自然算出 6。你本意是统计“订单数”或“地址数”，但没指定去重维度，数据库只能老实数行。
-
COUNT(*)数的是结果集里的行数，和业务语义无关 -
COUNT(orders.id)才真正表示“该用户有多少非空订单记录”，NULL 会被自动忽略 - 如果
orders.id允许为 NULL（极少见），得先COUNT(COALESCE(orders.id, -1))
什么时候必须用 COUNT(DISTINCT 字段)？
当你需要在已 JOIN 的宽表上直接统计某个从表的“数量类指标”，且该从表与主表是多对一或一对多关系时，COUNT(DISTINCT) 是最简方案。
- 统计每个用户的标签数：
COUNT(DISTINCT ut.tag_id)，不能写COUNT(DISTINCT *)（语法错误） - 字段必须来自被 JOIN 的表，且能唯一标识业务实体（如
order_id、addr_id） - 注意引擎支持：MySQL 8.0+、PostgreSQL、Trino 都支持；老版 Hive 可能不支持窗口内
COUNT(DISTINCT) OVER () - 性能提示：
DISTINCT会触发临时哈希表，大数据量时比预聚合慢
什么时候该用子查询预聚合代替宽表 JOIN？
当涉及多张一对多表（如 orders + order_items + user_tags），且需同时统计多个指标（订单数、商品总金额、标签数）时，预聚合是唯一可控方式。
- 子查询必须带
AS 别名，否则 MySQL 报Error Code: 1248 - 子查询内
GROUP BY必须是关联键（如user_id），只返回该键 + 聚合字段 - 外层
ON u.id = t.user_id的字段类型必须完全一致（别一边BIGINT一边VARCHAR） - 右表过滤条件（如
WHERE is_active = 1）必须写在子查询内部，写在外层会退化成INNER JOIN
LEFT JOIN 后 COUNT(字段) 为什么比 COUNT(*) 更可靠？
因为 COUNT(字段) 会跳过 NULL，而 COUNT(*) 不会——这是控制“是否保留零值”的关键开关。
- 想体现“没订单的用户订单数为 0”，必须写
COUNT(orders.id)，不是COUNT(*) - 想体现“所有部门（含无人部门）的员工数”，
LEFT JOIN users+COUNT(u.id)是标准写法 - 如果误用
COUNT(*)，没匹配的行仍计为 1，结果全错 - 注意：
COUNT(u.name)也有效，但前提是name非 NULL；若允许为空，优先用主键字段
最常被忽略的一点：预聚合子查询里的 WHERE 条件位置，以及 COUNT(DISTINCT) 中字段是否真能唯一标识业务实体——这两处出错，结果偏差不会报错，只会静默错漏。
