COUNT()在JOIN后偏大是因为统计的是连接后生成的行数而非主表原始行数，一对多关系导致主表1行扩展为N行，例如用户1行关联订单3行则COUNT()返回3。
为什么COUNT(*)在JOIN后总是偏大
COUNT(*)统计的是JOIN之后实际生成的行数，不是主表原始行数。一对多关系下，主表1行关联从表N行，就会变成N行参与COUNT，结果自然翻倍甚至更多。比如用户表1行 + 订单表3行 → JOIN后3行，COUNT(*)返回3，而不是1。
常见现象：COUNT(*)出现27、84这类明显异常值；EXPLAIN显示rows远大于主表记录数；分组后GROUP BY user_id返回行数却少于用户总数（说明有用户被漏掉或合并）。
别依赖COUNT(DISTINCT user_id)来“修复”——它只能掩盖膨胀，不能定位哪张表、哪个字段导致重复。
先确认是不是右表关联键不唯一
排查第一步不是改SQL，而是确认右表连接字段是否真唯一：
-
SELECT join_column, COUNT(*) FROM right_table GROUP BY join_column HAVING COUNT(*) > 1—— 如果有结果，说明该字段存在重复 -
SHOW CREATE TABLE right_table—— 看对应字段有没有UNIQUE或PRIMARY KEY约束 - 右表是视图或子查询？把它单独执行一遍，看输出里有没有重复
join_column
特别注意：业务上本该唯一，但历史数据可能有脏数据（如导入错误、未加约束），COUNT(*)暴增往往就藏在这类“看起来合理”的地方。
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聚合成单行。
正确做法是子查询或CTE先行压缩：
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字段必须和外层ON条件里的右表字段完全一致 -
LEFT JOIN未匹配时，聚合字段（如total_amount）会是NULL，SUM(NULL)返回NULL而非0 —— 需要显式写COALESCE(SUM(), 0) - 子查询里忘了加业务过滤（比如漏了
WHERE status != 'cancelled'），会导致聚合基数偏大
最易被忽略的点：预聚合不是写个GROUP BY就完事，字段对齐、空值处理、业务过滤缺一不可。一旦漏掉，结果照样错，而且更难排查。
