COUNT(*)在LEFT JOIN后偏大是因为统计连接后的物理行数而非主表行数；应改用COUNT(右表主键)或子查询预聚合，且右表筛选条件须放在ON而非WHERE中。
LEFT JOIN 本身不会“导致偏差”，偏差来自你对聚合函数和连接逻辑的误用——尤其是把 COUNT(*) 当成“主表行数”来用，或把右表筛选条件错放 WHERE 子句。
为什么 COUNT(*) 在 LEFT JOIN 后总比预期大
COUNT(*) 统计的是连接后生成的物理行数，不是左表原始行数。只要右表对左表主键存在一对多关系（比如一个用户有 3 条订单），JOIN 后这 1 行就变成 3 行，COUNT(*) 就返回 3。
- 错误写法：
SELECT u.id, COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id→ 没订单的用户也显示为 1（因为 LEFT JOIN 至少生成 1 行） - 正确写法：
SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id→o.id是主键，天然非 NULL，COUNT 只统计匹配成功的行，没订单用户返回 0 - 如果右表字段允许 NULL（如
o.status），又想按业务逻辑统计，得用：COUNT(CASE WHEN o.status IN ('paid', 'shipped') THEN 1 END)
WHERE 里过滤右表字段，LEFT JOIN 就失效了
写 LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'，效果等同于 INNER JOIN：所有 o.status IS NULL 的行（即没订单的用户）全被 WHERE 过滤掉。
- 修复方式只有一种：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 这样没订单的用户仍保留，
o.*全为 NULL，COUNT(o.id)得 0，语义才对 - 别写
WHERE o.status = 'paid' OR o.status IS NULL—— 逻辑混乱，且漏掉其他本该排除的状态（如'refunded'）
一对多关联时，SUM 或 COUNT 翻倍必须靠子查询预聚合
直接 JOIN 后再聚合，相当于在已膨胀的数据上硬算，结果必然失真。例如用户有 3 条订单、每条含 2 条明细，JOIN 后 1 行变 6 行，SUM(amount) 就被累加 6 次。
- 正确做法：先对右表按关联键聚合，再 LEFT JOIN
SELECT u.id, COALESCE(o_agg.total_amount, 0) FROM users u LEFT JOIN (SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status = 'paid' GROUP BY user_id) o_agg ON u.id = o_agg.user_id - 子查询里的
WHERE必须放在内部，不能丢到外层；GROUP BY字段必须和外层ON条件完全一致 - 子查询必须带别名（如
o_agg），否则 MySQL 报错Error Code: 1248
最常被忽略的点是：右表连接字段本身含 NULL 或类型不匹配，会导致关联失败——那些右表记录根本连不上左表，自然也不会被 COUNT 统计到，但你可能以为它们“应该出现”。查 SELECT COUNT(*) FROM orders WHERE user_id IS NULL 才能确认是不是数据质量问题。
