子查询中聚合函数易引发重复计算，关键在于避免相关子查询全表扫描、确保索引覆盖、将聚合提到外层、防止物化失效、下推过滤条件并精简分组字段。
子查询里用聚合函数会触发重复计算
当聚合函数出现在相关子查询中，数据库大概率为外层每一行都重新执行一次聚合。比如 SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = users.id) FROM users，如果 users 有 5 万行，而 orders.user_id 没索引，就等于执行了 5 万次全表扫描 orders 表——不是慢一点，是慢几万倍。
关键判断依据是 EXPLAIN 中出现 DEPENDENT SUBQUERY，且 rows 列数值巨大；或者 type 是 ALL 或 index，说明没走有效索引。
- 确保子查询中所有关联字段（如
user_id）都有索引，最好是联合索引覆盖WHERE和GROUP BY字段 - 把聚合逻辑提到外层：先用派生表算好每个
user_id的订单数，再LEFT JOIN回来 - 若子查询含
ORDER BY + LIMIT（如取最新一条），别硬转 JOIN，改用窗口函数或 CTE 预计算
聚合后嵌套在子查询里无法物化中间结果
MySQL 5.7 及更早版本对复杂子查询默认不物化，尤其当子查询含聚合、DISTINCT 或多层嵌套时，优化器宁可反复计算也不愿建临时哈希表。即使 MySQL 8.0+ 默认启用物化，一旦子查询里用了函数（如 DATE(created_at)）、隐式类型转换（如字符串 ID 和数字比较），或统计信息过期，物化就会被跳过。
典型表现是 EXPLAIN FORMAT=JSON 显示 "materialized": false，或执行计划里没有 MATERIALIZED 提示。
- 检查子查询是否对索引字段用了函数：把
WHERE DATE(created_at) = '2024-01-01'改成created_at >= '2024-01-01' AND created_at - 确认内外表字段类型和字符集完全一致，避免隐式转换导致索引失效
- 对高频子查询，显式加
/*+ MATERIALIZE */提示（仅 MySQL 8.0.19+ 支持）
主查询聚合能用索引下推，子查询聚合常被“隔离”
主查询中的 GROUP BY 若字段有索引，MySQL 可直接利用索引顺序归并分组，甚至避免 Using temporary; Using filesort。但子查询里的 GROUP BY 往往被当成独立单元处理，优化器看不到外层过滤条件，无法下推 WHERE 筛选，导致聚合基数爆炸。
例如主查询 SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY user_id 能走 (status, user_id) 索引；而子查询 (SELECT COUNT(*) FROM orders WHERE user_id = u.id AND status = 'paid') 即使有同样索引，也可能因驱动顺序问题退化为全表扫描。
- 子查询的
WHERE条件必须能命中索引最左前缀，否则下推失败 - 避免在子查询
GROUP BY中混入无业务意义的字段（如日志流水号），这会让分组数接近行数，强制落盘 - 如果聚合只涉及少数列，考虑建覆盖索引，让子查询免去回表
聚合函数本身不慢，慢在它前面没过滤
很多人盯着 COUNT(*) 或 SUM() 本身，其实瓶颈永远在它之前——子查询没加 WHERE 过滤，或过滤写在了 HAVING 里。一个没 WHERE 的子查询聚合，等于让数据库先扫完整张明细表，再分组，最后才扔掉不要的组。
对比：子查询 (SELECT COUNT(*) FROM orders WHERE user_id = u.id) 和 (SELECT COUNT(*) FROM orders WHERE user_id = u.id AND order_time >= '2024-01-01')，后者可能快 10 倍以上，因为提前筛掉了 95% 的行。
- 所有强筛选条件（时间范围、状态码、业务类型）必须写在子查询的
WHERE子句里，绝不能留到外层或HAVING - 避免
YEAR(order_time) = 2024这类写法，它无法走索引；改用范围查询 - 如果子查询结果稳定且复用频繁，直接建汇总表或物化视图，绕过实时聚合
WHERE，或多套一层无关函数，就可能让中间结果从内存膨胀到磁盘。
