innodb_buffer_pool_size应按热数据量估算而非物理内存比例，核心指标是innodb_buffer_pool_wait_free持续非零和innodb_buffer_pool_reads/innodb_buffer_pool_read_requests＞1%，同时结合pages made young与not young占比、os及进程内存预留、chunk与instances倍数约束动态调整。
别直接套“物理内存的 70%”——这个值在大多数生产环境里要么浪费，要么触发 OOM。
怎么判断 innodb_buffer_pool_size 设小了
看两个硬指标，不是命中率百分比：
-
Innodb_buffer_pool_wait_free持续非零增长：说明脏页刷出太慢或空间根本不够，线程在等空页 -
Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests比值 > 1%：比如每秒 5 万次逻辑读，1% 就是 500 次磁盘读，I/O 已成瓶颈 - 执行
SHOW ENGINE INNODB STATUS\G，在BUFFER POOL AND MEMORY段里找Pages made young和not young—— 如果not young占比过高（>30%），说明 LRU 链表老化过快，热数据留不住
设多大才真正合适
核心原则：按热数据量算，不是总数据量，更不是物理内存比例。
- 先估算活跃数据：用
SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' AND table_schema NOT IN ('mysql','information_schema','performance_schema');，再结合业务过滤（比如只查近 6 个月订单、用户行为日志） - 预留至少 2–4 GB 给 OS、
sort_buffer_size、连接线程栈、备份进程；64 GB 机器上，innodb_buffer_pool_size = 40G比48G更稳 - 云上小内存实例（如 2 GB）别超
1G；否则 swap 频繁，QPS 断崖下跌 - 单机纯 MySQL 可设到 75%，但上限建议 ≤ 256 GB——超过后初始化和预热延迟明显拉长
动态调大 innodb_buffer_pool_size 的实际限制
MySQL 5.7+ 支持 SET GLOBAL innodb_buffer_pool_size = ...，但不是写完就生效：
- 新值必须是
innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances的整数倍，否则会静默向下取整（比如你设 42G，但 chunk 是 128M、instances=8，实际生效可能是 40.96G） - 调大后若并发陡增，要立刻检查
SHOW ENGINE INNODB STATUS中的Buffer pool mutex waits——如果高，说明innodb_buffer_pool_instances没配够（建议 ≥8，每个实例控制在 1–2 GB） - 刚调完别急着压测：缓冲池扩容是分 chunk 渐进加载的，期间部分请求仍走磁盘，监控
Innodb_buffer_pool_resize_status看进度
容易被忽略的连锁反应
调大 buffer pool 不只是改一个参数的事：
- 它会吃掉更多连续虚拟地址空间，Windows 或某些容器环境可能报
[ERROR] InnoDB: Cannot allocate memory for the buffer pool，哪怕free -h显示内存充足 - buffer pool 超过 40 GB 后，
innodb_buffer_pool_dump_at_shutdown生成的 dump 文件可能达数 GB，下次启动时加载耗时几十秒，期间连接拒绝 - 没开
innodb_buffer_pool_load_at_startup=ON的话，重启后命中率归零，前几分钟所有查询都打磁盘——这在高流量服务里等于雪崩
