聚合后join比单独聚合慢十倍，是因为优化器常误判为“先关联再聚合”，导致全量拼接生成亿级中间结果；应确保关联字段有索引、字符集一致，并用left join或加约束引导优化器选择“先聚合后关联”路径。
聚合后 JOIN 为什么比单独聚合慢十倍？
因为数据库优化器可能放弃你写的“先聚合、再关联”逻辑，转而执行“先关联、再聚合”——它把几千万行明细数据和维度表全量拼接，生成上亿行中间结果，最后才分组。这不是你写的 SQL 语义，而是优化器在缺乏足够统计信息或索引时的误判。
典型表现是：子查询 SELECT sddm, ygdm, SUM(...) FROM ... GROUP BY sddm, ygdm 单独跑 1 秒；但一加上 INNER JOIN KEHU 和 INNER JOIN dianyuan，就涨到 30 秒以上，EXPLAIN 里能看到 Using temporary; Using filesort 或大量 rows_examined 突增。
- 强制走“先聚合后关联”的最简方式是改用
LEFT JOIN（即使业务上逻辑等价），因为优化器对LEFT JOIN更倾向保留左表驱动顺序 - 确保关联字段有索引且字符集/排序规则完全一致（比如两个
utf8mb4_0900_ai_ci字段才能高效走索引，混用utf8_general_ci会隐式转换导致索引失效） - 如果维度表没有主键或唯一约束，优化器可能不敢假设关联后行数不膨胀，进而拒绝下推聚合，建议补上
PRIMARY KEY或UNIQUE约束
GROUP BY 字段过多导致聚合变慢的根本原因
每多一个 GROUP BY 字段，分组桶数量不是线性增长，而是接近笛卡尔积级膨胀。例如按 store_id, user_id, order_time 分组，哪怕只有 100 家店、1 万用户、10 万订单，理论分组数上限是 100 × 10000 × 100000 —— 显然不可能全存内存，必然触发磁盘临时表和哈希重散列。
- 检查是否真需要秒级时间戳：用
DATE(order_time)或HOUR(order_time)替代原字段，大幅降低分组基数 - 避免在
GROUP BY中包含无业务意义的 ID（如日志流水号log_id），这类字段几乎 100% 独立，等于强制让每行自成一组 - MySQL 8.0+ 可开启
optimizer_switch='hash_join=off'临时禁用哈希连接，有时能迫使优化器选择更可控的排序合并连接（尤其当内存不足时）
WHERE 过滤写在聚合前还是后？别信 HAVING
HAVING 是聚合完成之后才执行的筛子，意味着数据库已经算完了全部分组、占满了内存、甚至写了临时文件，才开始扔掉你不想要的组。而 WHERE 是在扫描阶段就拦住 90% 的无效行——这对聚合性能是数量级差异。
- 把时间范围、状态码、类型标识等强筛选条件一律放在
WHERE，例如WHERE rq >= '2026-02-01' AND rq - 避免
HAVING COUNT(*) > 1这类写法；若目标是“复购客户”，优先用SELECT user_id FROM orders WHERE ... GROUP BY user_id HAVING COUNT(*) > 1改成子查询 +IN或窗口函数COUNT(*) OVER (PARTITION BY user_id) - 对日期字段慎用函数：写
YEAR(rq) = 2026会让索引失效，必须写成范围形式rq BETWEEN '2026-01-01' AND '2026-12-31'
聚合慢，加索引真的有用吗？
单加日期索引只能加速 WHERE 过滤，不能跳过聚合计算本身。真正起效的是覆盖索引：把 GROUP BY 字段和聚合字段一起包进索引，让引擎免去回表读取原始行。
- 例如聚合语句是
SELECT store_id, status, SUM(amount) FROM orders WHERE rq BETWEEN ... GROUP BY store_id, status，建索引应为INDEX idx_store_status_amount (store_id, status, amount) - 注意字段顺序：
GROUP BY字段必须前置，且顺序要和语句中一致；否则无法用于分组排序优化 - 如果聚合字段是表达式（如
SUM(price * qty)），索引无法直接覆盖，此时考虑物化视图（PostgreSQL）、汇总表（MySQL）或预计算列（MySQL 5.7+ 虚拟列 + 索引）
最容易被忽略的一点：聚合慢往往不是函数本身的问题，而是中间结果失控。盯紧 EXPLAIN 输出里的 rows 和 Extra，一旦看到 Using temporary，说明已经脱离内存计算范畴，该拆逻辑或建汇总表了。
