innodb_buffer_pool_size是唯一必须优先调的内存参数，其他缓存类参数在MySQL 8.0+中已移除或仅对MyISAM生效；其合理值需满足三硬约束：小于总内存并预留2–4GB给OS、不触发swap、匹配innodb_buffer_pool_instances；推荐设为总内存减OS及其他进程占用，如64GB服务器无其他大服务则设56g。
直接看结论：innodb_buffer_pool_size 是唯一必须优先调的内存参数，其他缓存类参数（如 key_buffer_size、query_cache_size）在现代 MySQL（8.0+）中要么已移除，要么仅对遗留 MyISAM 表生效，不应抢占主缓冲池资源。
怎么算 innodb_buffer_pool_size 的合理值
innodb_buffer_pool_size 的合理值不是“越多越好”，也不是“照搬文档写 70%”。真实配置需满足三个硬约束：
- 必须小于服务器总内存，且给 OS 至少预留 2–4GB（尤其当内存 ≥32GB 时）
- 不能导致 swap 活跃（用
free -h和swapon --show验证） - 需匹配 `innodb_buffer_pool_instances` —— 若设为 8，但实际缓冲池只有 1.5GB，则每个实例仅约 192MB，失去分片意义
推荐计算方式（专用 DB 服务器）：
innodb_buffer_pool_size = 总内存 - 4GB（OS 预留） - 其他进程内存（如 Redis、备份工具）
例如：64GB 内存服务器，无其他大内存服务 → 建议设为 innodb_buffer_pool_size = 56g；若还跑着一个 8GB Redis，则应压到 48g。
innodb_buffer_pool_instances 设多少才不白配
innodb_buffer_pool_instances 设多少才不白配这个参数不是“越大越好”，它控制缓冲池被划分为多少个独立子区域，目的是减少并发访问时的内部锁争用。但它只在缓冲池 ≥1GB 时才有意义。
常见误配：
- 设了
innodb_buffer_pool_instances = 16，但innodb_buffer_pool_size = 1g→ 每个实例仅 64MB，反而增加管理开销 - 设了
= 8，但 CPU 只有 4 核 → 实例数远超并发线程能力，调度收益递减
实用建议：
- 缓冲池 ≤8GB → 设为
1或2 - 8GB–64GB → 设为
4或8（优先选 8，MySQL 5.7+ 默认就是 8） - ≥64GB → 可设为
16，但务必通过SHOW ENGINE INNODB STATUS\G查看 “BUFFER POOL AND MEMORY” 部分，确认各实例分配均匀（Pages free、Pages made young差异不宜超 15%）
为什么 sort_buffer_size 不能全局调大
sort_buffer_size 不能全局调大很多人看到慢查询含 ORDER BY 或多表 JOIN，就直接 SET GLOBAL sort_buffer_size = 8m —— 这是高危操作。
原因很实在：
- 该内存是**每个连接独占**的，不是共享池。100 个并发连接 × 8MB = 800MB 瞬间吃掉
- 它不会自动释放，直到连接断开或显式重置（
SET SESSION sort_buffer_size = DEFAULT） - 超过
tmp_table_size/max_heap_table_size仍会退化为磁盘临时表，调大只是“假装优化”
更稳妥的做法：
- 保持全局默认（
sort_buffer_size = 256k），对特定慢查询用SET SESSION sort_buffer_size = 4m临时提升 - 优先优化 SQL：加索引覆盖
ORDER BY字段，避免SELECT *，缩小结果集 - 监控
Sort_merge_passes状态变量，持续 > 100/秒 才值得怀疑排序内存不足
关键点往往藏在细节里：innodb_buffer_pool_size 调得再准，如果 max_connections 没控住，或者 tmp_table_size 和 max_heap_table_size 不同步，照样会因临时表爆内存而触发磁盘落盘。调参不是填数字，是看资源流向。
