先聚合再JOIN通常性能更好，因其将N行压缩为M行（M≪N），显著降低JOIN的乘积级开销；前提是聚合可独立完成、过滤能下推、分组键有索引支撑。
先聚合再JOIN 通常性能更好，前提是聚合能独立完成、过滤条件可下推、分组键有索引支撑。这不是玄学，是数据量级和执行路径决定的硬约束。
为什么“先聚合再JOIN”在绝大多数场景下更快
核心在于中间结果集大小：JOIN 的代价大致与两个输入行数的乘积成正比，而聚合能把 N 行压缩成 M 行（M ≪ N）。比如 orders 表有 200 万行，users 表有 5 万行，直接 JOIN 后再 GROUP BY，数据库可能要处理上百万匹配行；而先对 orders 按 user_id 聚合，结果往往只有几万行，再 JOIN users，IO、内存、CPU 全部降维。
常见错误现象：
- EXPLAIN 显示外层
rows估算值接近 orders 原始行数（如 1.8M），而非聚合后行数（如 32K） - 执行时出现
Using temporary; Using filesort，说明聚合被迫在 JOIN 后做，且没走索引排序 - 慢查询日志里
Rows_examined高达千万级，但业务逻辑其实只关心几百个活跃用户
哪些情况会让“先聚合再JOIN”失效甚至更慢
不是所有聚合都能前置——关键看语义是否允许提前切分。典型失效点包括：
-
WHERE条件依赖右表字段（例如WHERE u.level = 'vip'），但聚合子查询没感知，导致统计了全部user_id，JOIN 后才丢弃非 VIP 行 → 结果错 + 白算 - 聚合子查询里用了
SELECT *或带大文本字段（如description），拖慢子查询本身，还让临时结果无法有效索引 - 分组键（如
order_id）在源表上无索引，导致子查询GROUP BY变成全表扫描 + 文件排序 - 聚合后结果仍超大（比如按分钟粒度聚合日志表，产出 500 万行），后续 JOIN 依然吃力
此时应优先检查过滤是否可下推（把 WHERE u.level = 'vip' 改成子查询里 JOIN users 再筛），或改用 EXISTS 剪枝。
MySQL 和 PostgreSQL 中怎么写才真正生效
语法只是表象，关键是执行计划是否真走“先聚后关”。实操要点：
- MySQL 5.7+：用派生表，确保子查询只含
GROUP BY键和聚合值，例如SELECT user_id, COUNT(*) AS cnt FROM orders WHERE status = 'PAID' GROUP BY user_id - PostgreSQL / MySQL 8.0+：CTE 更易读，但注意 CTE 在 PG 中默认不物化（除非加
MATERIALIZED），大结果集建议显式建临时表 - 必须给子查询的分组键建索引（如
CREATE INDEX idx_orders_user_status ON orders(user_id, status)），否则WHERE + GROUP BY很难走 range 扫描 - 聚合后若要多字段 JOIN（如连 address、profile），建议把子查询结果存为临时表，并对关联字段加索引：
CREATE TEMPORARY TABLE tmp_sum AS ...; CREATE INDEX idx_tmp_user_id ON tmp_sum(user_id);
如何验证你写的“先聚合再JOIN”真的快了
别靠感觉，用 EXPLAIN ANALYZE 看两处：
- 子查询节点的
type是ref或range（说明走了索引），而不是ALL - 外层
JOIN的rows估算值，应接近子查询输出行数，而非原始明细表行数 - 对比实际执行时间，注意排除缓存干扰（首次运行后清缓存再测，MySQL 可用
RESET QUERY CACHE或重启连接）
最容易被忽略的一点：聚合字段含 NULL（如 SUM(order_amount) 遇到全 NULL 分组返回 NULL），会导致 ON u.id = t.user_id 不匹配而丢行。务必检查子查询中分组键是否 NOT NULL，必要时加 WHERE t.user_id IS NOT NULL。
