MySQL buffer pool 应按活跃数据量而非物理内存比例设置，关键看 Innodb_buffer_pool_wait_free 是否非零及磁盘读占比是否超1%，动态调整需满足 chunk_size 对齐约束，并预留 OS 和连接私有内存。
别直接按物理内存百分比硬设，否则容易触发 swap 或 OOM Killer —— 这是线上 MySQL 崩溃最常见原因之一。
怎么看当前 buffer pool 是不是太小
别只盯着 Innodb_buffer_pool_hit_rate。99% 看着漂亮，但若 Innodb_buffer_pool_read_requests 每秒几万次，1% 就是几百次磁盘读，I/O 已经扛不住了。
真正该盯的两个硬指标：
-
Innodb_buffer_pool_wait_free持续非零或缓慢上涨 → 空闲页不足，线程在等内存 -
Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests > 0.01（即 >1%）→ 百次逻辑读就有一次走磁盘
用这条语句快速验证：
SELECT (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME ='Innodb_buffer_pool_read_requests') AS read_requests,
(SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME ='Innodb_buffer_pool_reads') AS disk_reads,
ROUND(100 - (disk_reads/read_requests)*100, 2) AS hit_rate_pct;如果 disk_reads 每秒稳定 > 10，基本可以判定偏小。
设多大才不爆内存也不浪费
热数据量才是上限锚点，不是物理内存。盲目套“70–80%”是事故高发原因。
实操步骤：
- 估算活跃数据：运行
SELECT SUM(data_length + index_length) FROM information_schema.tables WHERE engine='InnoDB' AND table_schema NOT IN ('mysql','information_schema','performance_schema') AND table_name IN ('orders_2024','user_profiles');（只算近 90 天高频访问的表） - 硬性预留至少 2GB 给 OS；混合部署（如共用 Redis/Elasticsearch）要额外扣掉对应内存；云上小实例（2–4GB 总内存）
innodb_buffer_pool_size别超 1GB - 单机纯 MySQL 可到 75%，但上限建议 ≤ 256GB（初始化和预热成本陡增）
典型参考值：
- 8GB 内存 → 设
innodb_buffer_pool_size = 4G - 32GB 内存 + Nginx/Redis（共占约 4GB）→ 剩余 28GB × 70% ≈ 20G
- 128GB 内存专库 → 100G 是较稳妥上限，而非 108G
动态调大失败？大概率踩了 chunk_size 对齐陷阱
MySQL 8.0 动态调大 innodb_buffer_pool_size 失败，报错 ERROR 1231 (42000): Variable 'innodb_buffer_pool_size' can't be set to the value of 'X'，大概率是没对齐 innodb_buffer_pool_chunk_size（默认 128MB）和 innodb_buffer_pool_instances 的乘积。
必须满足：innodb_buffer_pool_size = innodb_buffer_pool_chunk_size × innodb_buffer_pool_instances，否则 SET GLOBAL 会静默失败或回退。
查当前值：
SELECT @@innodb_buffer_pool_chunk_size, @@innodb_buffer_pool_instances, @@innodb_buffer_pool_size;
生产环境建议：
- 固定
innodb_buffer_pool_instances（如 8 或 16），只调innodb_buffer_pool_size - 确保
innodb_buffer_pool_size是 128MB（即 134217728 字节）的整数倍 - 避免在线调整时 chunk_size 被隐式重算导致不一致
最容易被忽略的一点：buffer pool 占用内存 ≠ 总内存开销。每个连接还会吃掉 sort_buffer_size、join_buffer_size 等私有内存，max_connections=500 + sort_buffer_size=4M 就能额外干掉 2GB。不把这块算进去，再“合理”的 buffer pool 都可能让系统喘不过气。
