COUNT(*)或SUM()在JOIN后偏大是因为一对多关系导致行膨胀，主表1行匹配从表N行即生成N行参与统计；应先查右表关联字段重复情况，再用子查询按关联键预聚合，并将过滤条件写入ON而非WHERE。
为什么COUNT(*)或SUM()在JOIN后总是偏大
COUNT(*)统计的是JOIN之后实际生成的行数，不是主表原始行数。一对多关系下，主表1行关联从表N行，就会变成N行参与COUNT，结果自然翻倍甚至更多。比如用户表1行 + 订单表3行 → JOIN后3行，COUNT(*)返回3，而不是1。
常见现象包括：COUNT(*)远大于预期、SUM(amount)明显偏高、分组后GROUP BY user_id返回行数却少于用户总数（说明有用户被漏掉或合并）。
怎么快速确认是哪张表引发了一对多膨胀
别直接改SQL，先查右表关联字段是否重复：
SELECT join_column, COUNT(*) FROM right_table GROUP BY join_column HAVING COUNT(*) > 1- 对比
COUNT(*)和COUNT(DISTINCT left_table.primary_key)：如果前者显著更大，基本可锁定膨胀 - 看执行计划里的
rows_examined是否远超左表总行数（比如 users 表10万行，却扫描40万行）
特别注意：右表如果是视图或子查询，得把它单独拎出来执行一遍；外键没加 UNIQUE 约束？用 SHOW CREATE TABLE 确认；历史脏数据也可能导致重复，不能只信业务逻辑。
LEFT JOIN后聚合失真时，子查询预聚合怎么写才不踩坑
核心是让“多”侧表先按关联键压缩成单行，再和主表拼接。子查询不是加个 GROUP BY 就完事，以下三点漏一个就白干：
-
GROUP BY字段必须和外层ON条件里的右表字段完全一致，比如子查询按order_id分组，外层就得写ON o.order_id = s.order_id，不能错写成ON o.id = s.order_id - LEFT JOIN未匹配时，聚合字段会是
NULL，SUM(NULL)返回NULL而非 0——必须显式用COALESCE(SUM(amount), 0) - 子查询里必须把业务过滤条件（如
WHERE status = 'paid'）写进去，漏掉会导致聚合基数偏大
示例（统计每个用户的订单总额）：
SELECT u.id, u.name, COALESCE(o.total_amount, 0) AS total_amount FROM users u LEFT JOIN ( SELECT user_id, SUM(amount) AS total_amount FROM orders WHERE status = 'paid' GROUP BY user_id ) o ON u.id = o.user_id;
ON和WHERE放错位置会让问题更隐蔽
LEFT JOIN 后对右表字段加 WHERE 过滤，比如 WHERE o.status = 'shipped'，会导致未匹配或状态不符的左表行被整体剔除——LEFT JOIN 退化成 INNER JOIN，你还以为“数据少了”，其实是“翻倍被掩盖了”。
正确做法是把过滤条件塞进 ON：
- 错误写法：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'shipped' - 正确写法：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'shipped'
区别在于：写在 ON 是“决定怎么连”，写在 WHERE 是“连完再筛”。后者膨胀已发生，前者从源头控量。MySQL 5.7+ 和 PostgreSQL 支持良好，但旧版 SQLite 或某些 ODBC 驱动可能不兼容，上线前务必实测。
AND deleted = 0，结果还是错的。 
