在配置innodb_buffer_pool_size时，不能只关注总内存，必须同时兼顾三个关键约束：系统可用内存、chunk与instances的整数倍对齐，以及实际数据热度。具体操作步骤：先用free -h查看a vailable列（注意不是total），然后确认当前chunk_size × instances的最小单位，例如默认 128M × 8 = 1G。对于小内存 VPS（≤2G），直接设为 256M 并关闭performance_schema更为稳妥。
如何正确设置 innodb_buffer_pool_size 避免踩坑？
如果直接采用固定百分比（例如“设为内存的75%”），往往会导致失败。它必须同时满足三个硬性约束：系统可用内存、innodb_buffer_pool_chunk_size 与 innodb_buffer_pool_instances 的整数倍对齐，以及实际数据热度。具体操作如下：
- 先检查真实可用内存：使用
free -h查看a vailable列，而非total——在混合部署的机器上，Redis、Java 进程，甚至 systemd 日志都会占用内存，仅看总量容易出错。 - 其次查询当前 chunk 和 instance 配置：执行
SELECT @@innodb_buffer_pool_chunk_size, @@innodb_buffer_pool_instances;默认值为 128M 和 8，因此最小调整单位是 1024M（1G），设置过小将不生效。 - 避免使用 MB/GB 作为单位编写配置：配置文件中只能使用
4G或4096M这样的格式，如果写成4GB或4096MB，MySQL 将无法启动，这个细节很容易被忽视。 - 对于小内存 VPS（≤2G），不要套用比例：直接设置
innodb_buffer_pool_size = 256M更为稳定，同时关闭performance_schema，可以节省大量内存。
innodb_buffer_pool_size 在线调大时为何报错 ERROR 1238？
MySQL 5.7.5 及以上版本支持在线调大，但并非随意修改都能成功。出现此错误，通常是因为忽略了版本限制或未对齐 chunk。具体原因如下：
- 对于 MySQL 5.7.4 及更早版本，该变量为只读属性，执行
SET GLOBAL必然报错，唯一解决方法是修改/etc/my.cnf并重启 MySQL，没有捷径。 - 在 5.7.5+ 版本中仍需满足对齐要求：假设当前
chunk_size=128M、instances=8，那么只能设置为 1024M、2048M、3072M 等整数倍数值。如果设为 1500M，MySQL 会自动向下取整到 1024M，表面看已调整，实际并未生效，这是一个常见的陷阱。 - 调整后必须立即验证：执行
SELECT @@innodb_buffer_pool_size;检查返回值是否与设置一致，不要仅凭命令未报错就认为成功，许多问题恰恰源于只关注执行结果。 - 动态调大仅修改运行时内存，MySQL 重启后会自动恢复旧值——因此必须同步写入配置文件，否则下次启动依然沿用原值，这一点很多人容易忽略。
如何准确查看命中率？不要相信 innodb_buffer_pool_hit_rate 字段
该字段在 MySQL 5.7 及以上版本中已被标记为“deprecated”，采用过时算法，数值虚高，参考价值极低。真正可靠的指标是以下两个：
- 核心指标：
Innodb_buffer_pool_read_requests（逻辑读）和Innodb_buffer_pool_reads（物理读），计算公式：(1 − Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) × 100%。 - 查询方法：执行
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%read%';，计算结果若低于 95%，则应考虑扩容或检查慢查询是否使用了索引。 - 命中率高但响应慢？查看
Innodb_buffer_pool_wait_free：如果该值持续大于 0，说明脏页刷盘跟不上，此时 buffer pool 并非不足，而是写压力过大，需要调整innodb_io_capacity或拆分写负载。 - 同时关注
Innodb_buffer_pool_pages_free：如果长期大于 30%，说明 buffer pool 设置过大；如果长期为 0 且命中率低，则说明缓存淘汰过于频繁，可能是热点数据分散或缺少主键导致无效缓存。
Buffer Pool 调大后，为什么 ps aux 显示 mysqld 内存远超配置值？
这是正常现象，innodb_buffer_pool_size 仅管理 InnoDB 缓冲池主块，并不包含其他开销。具体原因如下：
- 每个活跃连接额外消耗 1–2MB 内存：100 个连接大约增加 200MB，
max_connections设置过高会悄悄占用大量内存，不能忽视这一点。 sort_buffer_size、join_buffer_size、read_buffer_size等 per-connection 参数，会随连接数线性放大，总内存消耗非常可观。performance_schema默认开启，在小内存机器上可能占用 100MB 以上，资源紧张时建议关闭：设置performance_schema = OFF。- 控制块本身也会占用内存：约为缓存页大小的 5%，16KB 的页对应约 800 字节的控制块，总占用量不可忽略。
因此，当看到 RSS 比配置值高出 20%–30% 时，不必惊慌；但如果 swap 开始活动（vmstat 1 中 si/so 非零），那才是真正的内存不足，需要立即降低 buffer pool 或清理其他进程。此时再调整配置已经来不及了。
