buffer pool大小设多少才不浪费又不抖动
InnoDB缓冲池不是越大越好，也不是越小越省内存——关键看实际热数据量和系统内存余量。设太大，OS会杀MySQL进程；设太小，频繁刷脏页+磁盘IO飙升，SHOW ENGINE INNODB STATUS里能看到大量Pages flushed和pending writes。
- 常规经验：设为物理内存的50%–75%，但必须预留至少2GB给OS和其他进程（尤其是有swap或跑着其他服务时）
- 查真实压力：
SELECT (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_pages_data') * 16384 / 1024 / 1024 AS data_mb;看当前缓存了多少MB热数据，比总大小更有参考价值 - 别硬套“80%”：如果业务读写集中在几百万行，哪怕机器有128G内存，
innodb_buffer_pool_size设到32G可能就已饱和，再大只是让LRU链变长、冷数据占位、刷脏更慢
buffer pool分段（instances）该开几个
分段本质是把一个大锁拆成多个，避免高并发下所有线程抢同一个buf_pool->mutex。但开太多反而增加管理开销，且对小buffer pool毫无意义。
- 默认值
innodb_buffer_pool_instances=8只在innodb_buffer_pool_size >= 1G时生效；小于1G时强制归为1个instance，改了也白改 - 经验值：每1GB buffer pool配1个instance，上限通常不超过16；比如32G buffer pool，设成
16比32更稳，Linux下超过CPU核心数易引发调度争用 - 验证是否起效：
SELECT * FROM information_schema.INNODB_BUFFER_POOL_STATS;查POOL_ID列有几个不同值，少于预期说明没生效（常见于配置后没重启或size不够）
为什么调完buffer pool后QPS反而掉了一截
这不是错觉，是InnoDB在“重建缓冲池状态”：新分配的pool初始全是空页，老连接还在读旧page frame，同时后台线程疯狂预读+刷脏，CPU和IO双高。这个阶段可能持续几分钟，尤其当innodb_buffer_pool_dump_at_shutdown=ON且上次dump文件很大时。
- 上线前先做预热：启动后执行
SELECT COUNT(*) FROM table_name扫一遍主键索引，或用mysqlslap压测基础查询，让热数据提前载入 - 关掉自动dump（如果不需要快速恢复）：
SET GLOBAL innodb_buffer_pool_dump_at_shutdown=OFF;，否则每次重启都要从磁盘load dump文件，卡住初始化 - 注意
innodb_buffer_pool_load_at_startup：设为ON时，MySQL会在启动后异步加载dump文件，但若dump过期（比如表结构大改），加载的全是无效页，白白占内存
监控buffer pool是否真在高效工作
光看命中率（Buffer pool hit rate）没用——99.9%可能是假象，比如全表扫描把冷数据刷进来，命中率虚高，但查询响应时间拉长。
- 盯两个硬指标：
Innodb_buffer_pool_read_requests（逻辑读）和Innodb_buffer_pool_reads（物理读），算出真实命中率：(read_requests - reads) / read_requests；低于95%就得查是不是SQL没走索引或buffer太小 - 看脏页比例：
Innodb_buffer_pool_pages_dirty / Innodb_buffer_pool_pages_total，长期高于15%说明刷脏跟不上，要调大innodb_io_capacity或检查磁盘IOPS瓶颈 -
innodb_buffer_pool_resize_status字段能告诉你最近一次resize是否完成，没完成就别急着切流量——resize是在线的，但期间部分page访问会短暂阻塞
buffer pool调优最麻烦的从来不是参数本身，而是它和查询模式、磁盘延迟、甚至Linux内核页回收策略耦合太深。改完一个值，得等至少15分钟看SHOW ENGINE INNODB STATUS里的BACKGROUND THREAD和SEMAPHORES有没有异常排队，不能只盯着QPS数字点头。
