先聚合再JOIN，这可不是什么锦上添花的小技巧——当涉及到一对多关联时，如果不先聚合，金额翻倍、计数爆炸几乎是必然结果。原因很简单：JOIN只做行级拼接，不会自动去重。倒推回来，唯一的解法就是通过子查询或CTE，把各明细表按业务主键预聚合，然后再对齐连接。这一点是硬性要求，绕不过去。
聚合后数据无法直接JOIN？先确认是否真需要“聚合后再关联”
很多人卡在这一步，是因为下意识认为必须先 SUM() 或 COUNT() 完再去连其他表。但说实话，更常见也更高效的做法恰恰相反：先 JOIN，再聚合。举个例子，要统计每个客户的订单总金额和最新订单时间，正常写法应该是：
- 先用
INNER JOIN或LEFT JOIN把customers、orders、order_items连起来 - 在最外层
GROUP BY customers.id, customers.name，然后直接用SUM(oi.quantity * oi.unit_price)和MAX(o.order_date) - 而不是先算出一个“客户总金额临时表”，再拿这个结果去 JOIN 地址表——那样多一层子查询不说，还容易漏掉没有订单的客户
那什么时候才需要用“先聚合再关联”？只有当某张表天生只提供汇总值（比如日志表每天只存一条UV/PV），或者聚合逻辑复杂到在主查询中根本没法写的时候，才值得考虑这条路。
必须先聚合再JOIN时，子查询是最稳妥的写法
假设现在要显示每位客户的信息、他最近30天的订单数，以及所属城市的人口数据（城市人口来自另一张静态维度表 cities），这时候订单数必须预聚合：
SELECT c.customer_id, c.name, co.order_count, ci.population FROM customers c LEFT JOIN ( SELECT customer_id, COUNT(*) AS order_count FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '30 days' GROUP BY customer_id ) co ON c.customer_id = co.customer_id LEFT JOIN cities ci ON c.city_code = ci.code;
这里有几个关键点值得注意：
- 子查询必须带上别名（这里是
co），否则外部ON没法引用目标字段 GROUP BY写的字段，必须和子查询中非聚合的字段完全一致，不然 PostgreSQL/MySQL 8.0+ 会直接报错- 如果
customers表有千万级，但orders近30天的数据只占0.1%，那这个子查询实际扫描量其实很小，性能可控 - 别写成
WHERE c.customer_id IN (SELECT customer_id FROM orders...)——这种写法既没法利用索引，也不会返回order_count = 0的客户，得不偿失
用 CTE 替代嵌套子查询，提升可读性但不改变执行逻辑
当聚合逻辑变多时，比如同时要近7天、近30天、近90天的订单数，多层子查询会变得很难维护。这时候 CTE 是更好的选择：
WITH recent_orders AS (
SELECT
customer_id,
COUNT(*) FILTER (WHERE order_date >= CURRENT_DATE - INTERVAL '7 days') AS cnt_7d,
COUNT(*) FILTER (WHERE order_date >= CURRENT_DATE - INTERVAL '30 days') AS cnt_30d,
SUM(amount) FILTER (WHERE order_date >= CURRENT_DATE - INTERVAL '30 days') AS sum_30d
FROM orders
GROUP BY customer_id
)
SELECT c.name, ro.cnt_7d, ro.sum_30d, ci.province
FROM customers c
LEFT JOIN recent_orders ro ON c.customer_id = ro.customer_id
LEFT JOIN cities ci ON c.city_code = ci.code;
注意几点：
FILTER是 PostgreSQL 的独有语法；MySQL 要用SUM(IF(...))，SQL Server 则用SUM(CASE WHEN ... THEN ... END)- CTE 不是视图，不会自动物化，优化器仍然可能把它内联展开——所以性能和等价的子查询基本没区别
- 别在 CTE 里写
SELECT *，尤其后续 JOIN 的表也有id字段时，ro.id和c.id会产生冲突，平白增加麻烦
聚合后JOIN容易踩的坑：NULL值、重复行、类型隐式转换
一旦用上子查询或 CTE 预聚合，关联时那些不起眼的细节错误，直接就会让结果跑偏：
- 聚合子查询没写
LEFT JOIN而用了INNER JOIN：没有订单的客户直接被干掉了，而不是显示order_count = NULL - 关联字段类型不一致：比如子查询返回的
customer_id是BIGINT，但customers表里是VARCHAR，某些数据库会悄悄转成字符串再比较，索引也就跟着废了 - 聚合时忘了
DISTINCT：比如用户有多个收货地址，JOIN addresses后再COUNT(order_id)会重复计数——应该先用COUNT(DISTINCT order_id)或者提前去重 - 时间范围条件写在
ON而非WHERE：在LEFT JOIN里，把过滤条件放ON会让右表记录被过滤，效果等于INNER JOIN
说到底，真正难的不是写出语法正确的 SQL，而是判断哪一层该聚合、哪一层该关联，以及 NULL 到底代表“无数据”还是“数据缺失”。这得结合业务语义一层一层去验证，光看执行计划是不够的。
