COUNT(*)在JOIN后偏大是因为一对多关系导致行数膨胀，应改用COUNT(从表主键)或预聚合子查询解决，而非依赖GROUP BY硬扛或DISTINCT补救。
JOIN 后 COUNT 或 SUM 不准，不是函数写错了，是数据在 JOIN 阶段就已经被复制膨胀了——修复必须从连接逻辑和聚合时机入手，不能靠 GROUP BY 硬扛或加 DISTINCT 补救。
为什么 COUNT(*) 在 JOIN 后总是偏大
COUNT(*) 统计的是 JOIN 之后实际生成的行数，不是主表原始行数。一对多关系下，主表 1 行关联从表 N 行，就会变成 N 行参与统计。比如用户表 1 行 + 订单表 3 行 → JOIN 后 3 行，COUNT(*) 返回 3，而不是 1。
- 常见现象：查“每个用户订单数”，结果出现 27、84 这类明显异常值；EXPLAIN 显示
rows远大于主表记录数；分组后GROUP BY user_id返回行数却少于用户总数（说明有用户被漏掉或合并） - 别依赖
COUNT(DISTINCT user_id)来“修复”——它只能掩盖膨胀，不能定位哪张表、哪个字段导致重复 - 先执行
SELECT user_id, COUNT(*) cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY user_id HAVING cnt > 1，看哪些用户被复制了 - 再查
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 5，确认是否真有一对多，还是数据异常（如user_id为 NULL 或重复脏数据）
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) -
COUNT(o.id)在 MySQL/PostgreSQL 中通常能走索引，性能比COUNT(*)略优，尤其当右表很大但匹配率低时
一对多必须预聚合，不能靠 GROUP BY 硬扛
JOIN 后再 GROUP BY 主表字段，解决不了行膨胀问题——聚合是在膨胀后的结果集上做的，COUNT/SUM 都已失真。真正要统计“每个用户的订单总金额”，不能直接 JOIN 订单明细表再 SUM(amount)，而要把明细先按 order_id 聚合成单行。
- 正确做法是子查询或 CTE 先行压缩：
(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)等字段加索引
LEFT JOIN 中 WHERE 和 ON 放错位置会放大中间结果集
这不是语法错误，但效果类似笛卡尔积：本该被过滤掉的右表行，因为错误塞进 WHERE，导致 LEFT JOIN 先全量配对再过滤，内存和 IO 都白花了。
- 错误写法：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 先生成所有c.status IS NULL的组合，再干掉 - 正确写法：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 只拉符合条件的右表行，从源头控量 - 如果业务需要保留无客户匹配的订单，又只取活跃客户信息，
WHERE绝对不能碰右表字段 - 关联字段有重复值或
NULL也会让聚合失真：即使ON写对了，orders.order_id在明细表里重复两次、或order_items.order_id有NULL，都会让 JOIN 结果成倍膨胀
最易被忽略的是预聚合子查询的 GROUP BY 字段和外层 JOIN 条件没对齐，或者忘了处理 NULL——比如 LEFT JOIN 未匹配时，聚合字段为 NULL，SUM(NULL) 返回 NULL 而非 0。这些细节不显眼，但一出错就全盘失准。
