Buffer Pool太小是聚合查询磁盘I/O飙升的首要原因：因GROUP BY等操作需大范围扫描，若热数据页和索引页无法被缓存，将反复磁盘读页、淘汰页、再读页，导致Innodb_buffer_pool_reads持续>50/秒，并可能触发磁盘临时表。
Buffer Pool 太小是聚合查询磁盘 I/O 飙升的首要原因——不是索引没建好，而是数据根本没进内存。
为什么聚合查询特别吃 Buffer Pool
GROUP BY、SUM、COUNT(DISTINCT) 等操作常触发大范围扫描或临时表。InnoDB 每次读一行，实际加载的是整页（默认 16KB）。如果 innodb_buffer_pool_size 不够缓存参与聚合的热数据页和索引页，就会反复从磁盘读页、淘汰页、再读页——Innodb_buffer_pool_reads 持续 > 50/秒就是明确信号。
更隐蔽的是：即使有索引，ORDER BY 或 HAVING 条件也可能让 MySQL 把中间结果写到磁盘临时表（Created_tmp_disk_tables 上升），这又绕过了 Buffer Pool，直接打磁盘。
- 聚合字段无索引 → 全表扫描 → 大量随机读
- 聚合后排序（如
GROUP BY x ORDER BY SUM(y) DESC）→ 内存不足时落盘排序 → 顺序 I/O 爆增 - 多表 JOIN 后聚合 → 缓冲池需同时容纳多张表的关联页 → 容量压力翻倍
怎么设对 innodb_buffer_pool_size
别套“70%内存”这种模糊公式。先看真实负载：
- 执行
SHOW ENGINE INNODB STATUS\G，找Buffer pool hit rate—— 长期低于99%就得调大 - 查
SELECT (Pages_data*16384)/1024/1024 AS size_mb FROM information_schema.INNODB_BUFFER_POOL_STATS;，看当前用了多少 MB，别只看分配值 - 云上 4GB 实例？
innodb_buffer_pool_size别超1G，否则 OS 开始 swap，QPS 断崖下跌 - 64GB 物理内存？预留至少
12G给系统、连接线程（每个约4MB）、sort_buffer_size等，剩余再按0.85算缓冲池
动态调整要满足条件：SET GLOBAL innodb_buffer_pool_size = 42949672960;（40G）必须是 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances 的整数倍，否则报错 ER_UNKNOWN_ERROR。
配套必须开的三个开关
单设大 Buffer Pool 不够，得让数据“进得快、留得住、热得稳”：
-
innodb_buffer_pool_load_at_startup = ON：重启后自动加载上次 dump 的热点页，避免冷启动后第一波聚合全走磁盘 -
innodb_buffer_pool_dump_at_shutdown = ON：关机前把活跃页保存下来，下次启动有据可依 -
innodb_buffer_pool_instances = 8（≥32GB 内存时）：拆成多个实例，避免单锁瓶颈——否则聚合查询高并发时，所有线程卡在同一个 LRU list 上争锁
注意：innodb_buffer_pool_dump_pct 默认 25%，如果聚合涉及的数据很分散，建议提到 75，确保更多页被 dump。
聚合查询本身能做的 IO 减法
Buffer Pool 是底座，但 SQL 写法决定它承不承受得住：
- 别在
GROUP BY字段上用函数，比如GROUP BY DATE(created_at)→ 索引失效 → 全表扫 → Buffer Pool 白配 - 宽表聚合时，显式指定列，砍掉
SELECT *—— 少读一页，就少一次潜在的磁盘加载 - 用
EXPLAIN FORMAT=JSON看disk_reads字段（MySQL 8.0.22+），大于 0 就说明该算子已触碰磁盘，得优化 - 高频聚合结果考虑物化：用
CREATE TABLE ... SELECT预算好结果存起来，查时直接走索引，绕过实时计算
最易被忽略的一点：Buffer Pool 调大后，innodb_log_file_size 也得同步加大（比如从 48M 到 1G）。否则检查点太频繁，后台刷脏页会反向拖垮聚合查询的响应时间。
