LEFT JOIN后COUNT(*)统计的是JOIN生成的物理行数而非业务行；右表一对多会导致左表单行展开为多行，需用COUNT(右表非空字段)或子查询预聚合避免膨胀。
LEFT JOIN后COUNT(*)统计的是物理行，不是业务行
它数的是JOIN之后实际生成的每一行，而不是你心里想的“每个用户算一次”。只要右表对左表主键存在一对多关系，1 行主表就会被展开成 N 行。比如 users 表里 1 个用户，在 orders 表中有 3 条记录，LEFT JOIN 后就变成 3 行，COUNT(*) 自然返回 3。
常见错误现象包括：COUNT(*) 出现 27、84 这类明显异常值；EXPLAIN 显示 rows_examined 远高于左表原始行数（如 users 有 10 万行，却扫描了 45 万行）；GROUP BY u.id 后返回行数反而少于用户总数（说明部分用户因右表 NULL 被合并或漏掉）。
别把过滤条件写在WHERE里，必须塞进ON子句
这是线上最常踩的坑：把右表的过滤条件放在 WHERE，等于先全量配对再砍掉不匹配行——中间结果早已膨胀。例如：
错误写法：LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active' → 实际等效于 INNER JOIN，且白跑一遍 NULL 匹配。
正确写法：LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active' → 从源头只拉符合条件的右表行，左表所有记录都保留。
注意：MySQL 5.7+、PostgreSQL 支持良好，但某些旧版 SQLite 或 ODBC 驱动可能不识别 AND 后的条件，上线前务必实测。
用子查询预聚合才是治本解法，不是加DISTINCT能绕过去的
DISTINCT 只能去最终结果的行，不能阻止中间膨胀，性能差、语义模糊，还容易掩盖真实数据问题。真正可靠的解法是让右表在 JOIN 前就按关联字段压缩成单行。
- 子查询必须严格
GROUP BY关联字段（如user_id），漏掉就等于没做 - 外层
ON条件必须和子查询GROUP BY字段完全一致（如子查询GROUP BY o.user_id，外层就得写ON u.id = o.user_id） - 过滤条件（如
status = 'paid'）必须写在子查询内，放在外层WHERE会导致先膨胀再过滤 - MySQL 报
Error Code: 1248. Every derived table must have its own alias，就是漏了子查询别名——必须加AS alias_name
COUNT(*) 和 COUNT(右表字段) 语义完全不同
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；如果字段允许 NULL（如 o.status），又必须按业务逻辑统计（比如只算 status IN ('paid', 'shipped')），就得用 COUNT(CASE WHEN o.status IN ('paid', 'shipped') THEN 1 END)。
复杂点在于：膨胀不是“会不会发生”，而是“只要一对多没处理，就一定发生”。很多人试图靠调整 GROUP BY 位置或加 DISTINCT 来掩盖，但数据库执行计划里早已经过百万行扫描——性能和语义都已受损。真正要盯住的，永远是 JOIN 前的数据形态。
