count(*)在join后大于左表行数，是因为一对多关系导致物理行数膨胀，如users表100行与orders表平均3单关联后变为约300行，并非函数错误而是数据被拉平。
JOIN后COUNT(*)为什么总是大于左表行数
因为COUNT(*)统计的是JOIN之后的物理行数，不是业务实体数。一对多关系下，左表1行匹配右表N行，结果就是N行——函数没出错，是数据被拉平了。比如users表100行，orders表里每个user_id平均对应3条记录，LEFT JOIN后就变成约300行，COUNT(*)自然返回300。
常见误判：COUNT(DISTINCT u.id)能“修好”总数，但它只是绕过问题，不解决膨胀根源。上线前必须确认：这个300到底是100个用户 × 平均3单，还是有20个user_id重复、实际只有80个有效用户。
- 先跑
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id ORDER BY COUNT(*) DESC LIMIT 5，看是否存在异常高频user_id - 再对比
SELECT COUNT(*) FROM users和SELECT COUNT(*) FROM users u LEFT JOIN orders o ON u.id = o.user_id，差值就是膨胀量 - 查执行计划，如果
rows_examined远超左表原始行数（比如users 10万行，却扫描45万行），基本锁定是JOIN膨胀
LEFT JOIN中WHERE条件放错位置会放大问题
把右表过滤条件写在WHERE里，等于主动制造膨胀再砍掉——先全量JOIN（含NULL），再过滤，中间已生成大量无效行。例如LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'，效果等同于INNER JOIN，且性能更差。
正确做法是把过滤塞进ON子句：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'。这样右表只拉符合条件的行进来，从源头控量。
- ORM自动生成SQL时容易漏掉这个细节，建议人工检查每个
LEFT JOIN后的ON是否包含全部业务约束 - 如果业务要求保留所有用户（包括没下单或订单状态不符的），WHERE里绝不能出现
o.xxx字段，否则LEFT语义就失效了 - 用
EXPLAIN看type是否为ALL、Extra是否含Using join buffer，这是漏ON条件的明确信号
多表LEFT JOIN串起来为什么会指数级膨胀
两个LEFT JOIN串在一起，如果右表各自一对多，结果就是乘法级：A表1行 × B表3行 × C表2行 = 6行，而不是你预期的1+3+2=6行。典型错误是直接LEFT JOIN b ON a.id = b.a_id LEFT JOIN c ON a.id = c.a_id，然后COUNT(c.id)返回的其实是B的行数（3），不是C的真实计数。
唯一可靠解法是把每个右表独立预聚合，压缩成每关联键一行，再JOIN主表。子查询必须严格GROUP BY关联字段，漏掉就等于没做。
- 子查询别名要明确，例如
(SELECT a_id, COUNT(*) AS item_cnt FROM order_items GROUP BY a_id) items - 外层
ON必须和子查询GROUP BY字段完全一致，比如子查询GROUP BY o.user_id，外层就得写ON u.id = o.user_id - 过滤条件（如
status = 'paid'）必须写在子查询内，放在外层WHERE会导致子查询输出仍含无效行
COUNT(DISTINCT)只能救急，不能替代逻辑修复
COUNT(DISTINCT order_id)在“查用户下了几单”这类场景下能绕过重复计数，但它只适用于个数类聚合，且掩盖真实数据问题。一旦涉及金额、时间等非离散值，SUM(DISTINCT amount)语义就全毁了——两笔100元订单会被算成一次100元。
DISTINCT是最终输出层动作，无法阻止JOIN阶段的行复制，性能也更差（需哈希去重，无法走索引）。如果子查询里漏了AND deleted = 0或时间范围，COUNT(DISTINCT)依然会错。
- 优先定位并修复JOIN逻辑，而不是依赖
DISTINCT兜底 - 上线前必须验证去重前后关键指标是否一致，特别是分页总数与明细行数是否对得上
- 如果必须用
DISTINCT，记得检查执行计划是否触发临时表或文件排序，大表上性能损耗明显
