子查询中使用SUM或COUNT慢是因为数据库无法复用中间结果，每次外层行匹配都需重算聚合，且MySQL 5.7前基本不优化，8.0后含GROUP BY仍易退化为嵌套循环。
子查询里套 SUM 或 COUNT 为什么慢
因为数据库无法复用中间结果，每次外层行匹配时都得重跑一遍聚合。比如 WHERE id IN (SELECT user_id FROM orders GROUP BY user_id HAVING SUM(amount) > 1000)，如果外层有 10 万行，这个子查询可能被触发 10 万次——哪怕它只依赖 orders 一张表。
更糟的是，MySQL 在 5.7 及以前版本对这类关联子查询基本不优化，执行计划里常出现 DEPENDENT SUBQUERY，意味着它必须逐行求值；即使 8.0 启用了 semijoin 优化，一旦子查询含 GROUP BY + 聚合，优化器仍大概率退回到嵌套循环。
- 聚合结果无法物化索引：子查询输出是临时结果集，没有索引，后续过滤或连接全靠扫描
- 内存压力大：若聚合中间状态（如分组键+sum）超出
sort_buffer_size，会落盘生成磁盘临时表 - 统计信息失真：优化器难准确估算分组后行数，容易选错驱动表或连接算法
CREATE VIEW 预计算不是万能的，关键看是否可增量更新
建视图本身不提升性能，只是封装 SQL；真正起作用的是把聚合结果固化到物理表或利用物化能力。MySQL 原生不支持物化视图，但可通过以下方式模拟：
- 用
CREATE TABLE AS SELECT ... GROUP BY构建汇总表，再定时用INSERT ... ON DUPLICATE KEY UPDATE增量刷新 - 在支持物化视图的数据库（如 PostgreSQL 9.4+、Oracle、SQL Server）中，直接定义
CREATE MATERIALIZED VIEW并设刷新策略 - 若只能用视图，确保其定义不含关联字段（即非相关子查询），否则每次调用仍会重算
例如，把高频查询 SELECT user_id, SUM(amount) FROM orders WHERE order_date >= '2026-01-01' GROUP BY user_id 提前算好存为 daily_user_revenue 表，并在 user_id 上建主键，外层查询就能走等值查找而非反复聚合。
替代 IN (SELECT ... GROUP BY) 的三种可行写法
不要指望加个索引就能救活带聚合的子查询——结构问题得从逻辑上拆解。下面三种改法在 MySQL 和 PostgreSQL 中都实测有效：
- 用
JOIN+ 汇总表：先算好聚合结果到临时表或持久表，再和主表JOIN。注意JOIN条件必须是等值，且汇总表要有合适主键/索引 - 用
EXISTS+ 相关子查询改写：把HAVING条件挪进子查询的WHERE，避免分组。例如将IN (SELECT user_id FROM orders GROUP BY user_id HAVING SUM(amount) > 1000)改为EXISTS (SELECT 1 FROM orders o2 WHERE o2.user_id = u.id GROUP BY o2.user_id HAVING SUM(o2.amount) > 1000)——虽仍相关，但部分版本能用松散索引扫描（loosescan）加速 - 用窗口函数替代（仅限需要 Top-N 场景）：如查“每个用户金额最高的 3 笔订单”，用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC)比嵌套聚合子查询快一个数量级
容易被忽略的两个硬限制
一是 MySQL 的 tmp_table_size 和 max_heap_table_size 默认仅 16MB，而百万级分组聚合很容易突破，导致强制落盘，IO 成瓶颈；二是即使你建了覆盖索引，如 INDEX (user_id, amount)，SUM(amount) GROUP BY user_id 仍需回表或文件排序——因为 GROUP BY 需要按 user_id 排序，而索引顺序未必匹配，除非显式加 ORDER BY user_id 且优化器选择索引扫描。
真正省事的做法，是把聚合逻辑从 SQL 层下沉到应用层定时任务或流处理（如 Flink 实时累加），让数据库只做点查。否则，任何“自动优化”都抵不过数据量翻倍后的线性退化。
