不能设为64G，因OS需4–8GB内存管理文件系统、网络栈和page cache，且其他进程（如监控agent、备份脚本）也需内存；硬塞满会触发swap，拖垮性能，而innodb_buffer_pool_size是预分配连续内存块，必须启动时锁定。
MySQL 5.7 在 64GB 内存服务器上，innodb_buffer_pool_size 必须设为 40G–48G，否则绝大部分内存被闲置，性能无法提升。
为什么不能直接设成 64G？
MySQL 不是唯一运行的服务；OS 需要至少 4–8G 缓存文件系统、网络栈和 page cache；其他进程（如备份脚本、监控 agent、应用服务）也会占用内存。硬塞满会导致频繁 swap，反而拖垮响应速度。
- Linux 内核会主动缓存磁盘读取，这部分内存可被 MySQL 动态挤占，但不能依赖它替代
innodb_buffer_pool_size -
innodb_buffer_pool_size是预分配的连续内存块，必须在启动时锁定（innodb_buffer_pool_instances分片后更稳定） - 若启用了
query_cache_size（已弃用），它也吃内存，且与 buffer pool 无协同，建议设为0
关键参数怎么配才不翻车？
以 64GB 物理内存、纯 InnoDB、高并发 OLTP 场景为例，my.cnf 中这些值不是“越大越好”，而是相互制约：
-
innodb_buffer_pool_size = 44G：留出 20G 给 OS + 其他进程，足够覆盖热数据和索引 -
innodb_buffer_pool_instances = 8：避免单实例锁争用，每 instance 约 5.5G，匹配现代多核 CPU -
innodb_log_file_size = 1G：配合innodb_log_files_in_group = 2，总日志空间 2G，减少 checkpoint 频率（别用默认 48M） -
max_connections = 2000：每个连接至少消耗 2–3MB（含sort_buffer_size、join_buffer_size等），2000 连接 ≈ 占用 5–6G 内存，需严格评估真实并发量 -
tmp_table_size = 512M和max_heap_table_size = 512M：防止大 GROUP BY 或 ORDER BY 触发磁盘临时表，但设太高易 OOM
改完不生效？先盯住这三件事
很多“调了没用”其实是配置没真正加载或验证方式错：
- 确认 MySQL 加载的是你改的配置文件：运行
mysqld --verbose --help | grep "Default options"，看输出路径是否为你编辑的/etc/my.cnf或C:\ProgramData\MySQL\MySQL Server 5.7\my.ini - 重启必须干净：
systemctl restart mysqld（Linux）或在 Windows 服务管理器中“重新启动” MySQL57，不是“停止+启动”——残留进程会沿用旧 buffer pool - 验证必须用
SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size';，不要只看SHOW VARIABLES（它返回会话级值，可能被动态修改覆盖）
最常被忽略的是：buffer pool 大小调整后，首次冷启动需要数分钟“预热”，期间大量磁盘读取是正常的；真正瓶颈往往不在内存大小，而在 innodb_log_file_size 过小导致频繁刷脏页，或 max_connections 虚高引发线程创建风暴。盯着 SHOW ENGINE INNODB STATUS 里的 “BUFFER POOL AND MEMORY” 和 “LOG” 段，比盲目加内存有用得多。
