count()在left join后不是主表行数，因为它统计的是join后生成的物理行数；一对多关系导致主表1行膨胀为n行，如用户1行关联3订单则count()返回3；应改用count(右表主键)或预聚合子查询修复。
LEFT JOIN后COUNT(*)为什么不是主表行数
COUNT(*)统计的是JOIN之后实际生成的物理行数，不是主表原始行数。一对多关系下，主表1行匹配右表N行，就变成N行参与COUNT——比如users表1行 + orders表3行，JOIN后就是3行，COUNT(*)返回3，而不是1。
常见现象包括：COUNT(*)结果出现27、84这类明显异常值；EXPLAIN显示rows远大于左表记录数；GROUP BY user_id后返回行数却少于用户总数（说明有用户被漏掉或合并）。
COUNT(o.id)比COUNT(*)准确的关键原因
COUNT(*)和COUNT(o.id)语义完全不同：COUNT(*)数所有行，COUNT(o.id)只数o.id IS NOT NULL的行。而主键天然非空，所以它准确反映“主表每条记录匹配了多少从表有效行”。
- 错误写法：
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)
子查询预聚合才是治本解法
不能靠DISTINCT或调整GROUP BY位置来“掩盖”问题，必须在JOIN前把多端数据压缩成每关联键一行。子查询必须严格GROUP BY关联字段（如user_id），外层ON条件必须和它完全一致。
- 过滤条件（如
status = 'paid'）必须写在子查询内，放在外层WHERE会导致先膨胀再过滤 - MySQL报
Error Code: 1248. Every derived table must have its own alias，就是漏了别名——子查询必须带AS alias_name - 中间表的
user_id是BIGINT，主表users.id也必须是BIGINT，类型不一致会让索引失效 - 示例：统计每个用户的有效订单数
SELECT u.id, u.name, COALESCE(o.order_cnt, 0) AS order_cnt<br>FROM users u<br>LEFT JOIN (<br> SELECT user_id, COUNT(*) AS order_cnt<br> FROM orders WHERE status = 'paid'<br> GROUP BY user_id<br>) o ON u.id = o.user_id;
为什么DISTINCT只是补救，不是修复
COUNT(DISTINCT o.id)能在已发生JOIN的查询中快速兜底，但它只适用于“个数类”统计，且掩盖真实数据问题。
-
COUNT(DISTINCT order_id)有效：你想知道“这个用户下了几单”，而orders表已和明细表JOIN过 -
SUM(DISTINCT amount)无效：金额去重后语义全毁，同一用户两笔100元订单会被算成一次100元 -
DISTINCT是最终输出层动作，无法阻止JOIN阶段的行复制，性能也更差（需哈希去重，无法走索引） - 如果子查询里漏了
AND deleted = 0或时间范围，COUNT(DISTINCT)依然会错
真正容易被忽略的点是：膨胀发生在JOIN阶段，不是COUNT函数的问题——所有修复都必须从连接逻辑和聚合时机入手，而不是在SELECT里调函数参数。
