COUNT(*)在JOIN后偏大是因为它统计JOIN结果集的行数，而非主表原始行数；一对多关系导致主表1行扩展为N行，应改用COUNT(从表主键)或预聚合解决。
JOIN后COUNT(*)为什么总是偏大
因为COUNT(*)统计的是JOIN之后实际生成的行数，不是主表原始行数。一对多关系下，主表1行关联从表N行，就会变成N行参与统计——比如用户表1行 + 订单表3行 → JOIN后3行，COUNT(*)返回3，而不是1。
常见现象包括：查“每个用户订单数”，结果出现27、84这类明显异常值；EXPLAIN显示rows远大于主表记录数；分组后GROUP BY user_id返回行数却少于用户总数（说明有用户被漏掉或合并）。
别依赖COUNT(DISTINCT user_id)来“修复”——它只能掩盖膨胀，不能定位哪张表、哪个字段导致重复。
用COUNT(从表主键)替代COUNT(*)
COUNT(*)和COUNT(o.id)语义完全不同：COUNT(*)数所有行，COUNT(o.id)只数o.id IS NOT NULL的行。而主键天然非空，所以COUNT(o.id)准确反映“主表每条记录匹配了多少从表有效行”。
- 错误写法：
SELECT u.id, COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id→ 没订单的用户也显示1 - 正确写法：
SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id→ 没订单用户返回0 - 必须确保字段是主键或明确定义为
NOT NULL，否则COUNT(o.status)会漏掉状态为空的订单 - 如果从表该字段允许
NULL，又必须按业务逻辑统计（比如只算status IN ('paid', 'shipped')），就得用COUNT(CASE WHEN o.status IN ('paid', 'shipped') THEN 1 END)
一对多必须预聚合，不能靠GROUP BY硬扛
JOIN后再GROUP BY主表字段，解决不了行膨胀问题——聚合是在膨胀后的结果集上做的，COUNT/SUM都已失真。真正要统计“每个用户的订单总金额”，不能直接JOIN订单明细表再SUM(amount)，而要把明细先按order_id聚合成单行。
例如统计每个客户的订单总金额和订单数（订单明细可能有多条）：
SELECT c.name, co.total_amount, co.order_count FROM customers c LEFT JOIN ( SELECT order_id, SUM(amount) AS total_amount, COUNT(*) AS order_count FROM order_items GROUP BY order_id ) co ON c.id = co.order_id;
注意：GROUP BY order_id是关键，把明细压缩成每单一行；如果要统计客户维度（不是订单维度），子查询应GROUP BY customer_id，并确保外层JOIN键一致。
COUNT(DISTINCT 主键)是兜底方案，不是治本之法
在已发生JOIN的查询中，不改结构的前提下，用COUNT(DISTINCT o.id)替代COUNT(*)可快速修复“车主数”“订单数”类统计。但这是补救，不是根治。
适用场景：
- 主表ID明确非空、唯一，且你想统计“有多少个主表实体被关联到”
- 临时排查或报表SQL不能大改时的兜底方案
- MySQL / PostgreSQL / SQL Server均支持，语法无兼容性风险
多列组合去重必须用子查询包装：想统计“不同车主+城市组合数”，不能写COUNT(DISTINCT o.id, o.city)——MySQL和SQL Server会报错，PostgreSQL虽支持但语义易混淆。正确做法是把去重逻辑提前。
真正容易被忽略的点是：重复不是发生在GROUP BY阶段，而是在JOIN阶段就已注定。看到COUNT虚高，第一反应不该是调GROUP BY，而是回溯JOIN结果集——用SELECT *看几行、用SELECT user_id, COUNT(*) FROM ... GROUP BY user_id确认膨胀程度。
