为啥LEFT JOIN后SUM会翻倍呢？那是因为当主表的一行关联子表的N行时，会复制出N行去参与聚合，这样一来，SUM、COUNT等就会按照物理行重复累加啦。正确的做法是，用子查询先对子表按照关联键进行预聚合（比如说GROUP BY user_id），然后再LEFT JOIN主表，并且要用COALESCE来处理NULL哦。

为什么LEFT JOIN后SUM会翻倍

由于主表的一行会关联到子表的N行，JOIN操作会复制出N行来参与后续的聚合，像SUM、COUNT这些操作的结果自然就会放大N倍。这并非数据库的bug，而是关系代数的必然。打个比方，当我们查询“每个用户的订单总金额”时，在执行users LEFT JOIN orders后直接计算SUM(orders.amount)，得到的数值可能会比实际高出好几倍。

预汇总能避开中间结果集爆炸

三张百万级表JOIN可能生成上千万行临时数据，而聚合本身单次扫描即可完成。把SUM塞在JOIN之后，等于让数据库先拼出全部组合再统计；预汇总则是先对子表按user_id或order_id压缩成每逻辑单位一行，再JOIN，中间数据量从千万级压到百万级甚至更少。

• 聚合子查询必须只返回分组键 + 聚合值，例如：SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id
• 外层JOIN键必须严格匹配该分组键，且子查询需带别名（MySQL报Error Code: 1248常因漏AS t）
• 子查询里的过滤条件（如WHERE status = 'paid'）必须写在内部，挪到外层WHERE会把LEFT JOIN变成INNER JOIN

不预汇总时DISTINCT救不了SUM和A VG

COUNT(DISTINCT id)能绕过重复计数，但它只解决“个数”问题；SUM(DISTINCT amount)会去重金额值，逻辑完全错误。大数据量下DISTINCT还需哈希去重，比预汇总更慢，且无法利用索引优化。

• 适用：COUNT(DISTINCT orders.id)统计每个客户下了几个订单
• 不适用：SUM(DISTINCT orders.amount)算总销售额——它会把相同金额只加一次
• 真正要的是：先在子查询里GROUP BY user_id算好每人总额，再JOIN

CTE和子查询选哪个

执行计划通常等价，但CTE更易读、可复用。比如同一张order_items表既要算总金额又要算商品数，用CTE只扫描一次；而嵌套子查询若重复写两次，可能被优化器分别执行。

• CTE适合多处引用同一聚合结果，或逻辑分层清晰的场景
• 简单单次引用，子查询更轻量，避免物化开销（尤其当明细表已有覆盖索引时）
• SQLite不支持写入式CTE，但查询类CTE可用；MySQL 8.0+、PostgreSQL 12+均推荐优先用CTE显式表达意图

预汇总不是“多写几行SQL”的负担，而是把聚合粒度控制权从数据库执行引擎手里拿回来——否则你永远不知道SUM到底是在对多少行求和。