join后sum/count翻倍是因一对多关系导致笛卡尔积膨胀，主表一行被复制多次参与聚合；正确解法是先对子表按关联键预聚合（如group by user_id）再left join，并将过滤条件下推至子查询内、用coalesce处理null。
直接在一对多 JOIN 后用 SUM 或 COUNT，结果必然失真——这不是写法错，是数据物理结构决定的。必须把聚合“收口”到 JOIN 之前。
为什么 JOIN 后 SUM 和 COUNT 会翻倍？
一对多关系下，JOIN 会把主表一行“复制”多次。比如一个用户有 3 笔订单、2 张发票，INNER JOIN 后生成 3 × 2 = 6 行，SUM(invoice.amount) 就被累加了 3 次，SUM(sale.amount) 被累加了 2 次。
- 验证方法：
SELECT user_id, COUNT(*) FROM users u JOIN orders o ON u.id = o.user_id GROUP BY user_id，看单个user_id是否对应多行 -
COUNT(*)返回大于 1，说明已膨胀；此时再套SUM就没意义 - 别用
DISTINCT硬压——它不解决重复计算，只掩盖问题，还可能误删合法组合（如同一用户不同渠道的相同金额订单）
先聚合再 LEFT JOIN：最通用且兼容性最好的解法
核心是把“一对多”提前压缩成“一对一”，让主表不被复制。每个子表单独 GROUP BY + 聚合，再以主表为驱动 LEFT JOIN 这些中间结果。
- 所有过滤条件（如时间范围、状态）必须下推到子查询里，不能写在外层
WHERE，否则LEFT JOIN会退化成INNER JOIN - 子查询必须带显式别名（MySQL 报
Error Code: 1248就是因为漏了AS t） - 关联字段类型必须一致（如
users.id是BIGINT，子查询里的user_id也得是BIGINT），否则索引失效 - 用
COALESCE(t.amt, 0)处理 NULL，不只是为了显示好看——NULL 可能导致前端崩溃或报表归零
SELECT u.id, u.name, COALESCE(o.total_amt, 0) AS order_total, COALESCE(i.total_amt, 0) AS invoice_total FROM users u LEFT JOIN ( SELECT user_id, SUM(amount) AS total_amt FROM orders WHERE status = 'paid' AND create_time <h3>需要明细字段时，别硬套子查询</h3> <p>如果除了总金额，还要最新一笔订单的 <code>order_no</code> 或 <code>created_at</code>，子查询预聚合就不够用了——它只返回聚合值，丢掉了原始行细节。</p>
- 优先用窗口函数：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，然后在ON条件里加AND rn = 1，保留无订单的用户 - 错误写法：
WHERE rn = 1—— 这会把没订单的用户全过滤掉，LEFT JOIN变成INNER JOIN - 老版本 MySQL（EXPLAIN 是否触发全表扫描
- 若只需判断“是否存在”，改用
EXISTS更安全高效，天然规避重复和 NULL 陷阱
ON 和 WHERE 放过滤条件的区别很关键
中间表参与 LEFT JOIN 时，过滤位置直接决定是否丢失“没关联的主表记录”。
- 错：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'→ 没订单或订单非 paid 的用户全被过滤 - 对：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'→ 保留所有用户，只关联符合条件的订单 - 想查“status = 'paid' 的所有订单及其用户”，就该用
INNER JOIN，这时WHERE和ON效果等价
真正难的不是写出语法正确的 SQL，而是分清你要的是聚合值、单条明细，还是存在性判断——选错路径，后面所有优化都是白忙。
