参数模板是什么
参数模板给的是一个起点而不是答案：调整顺序通常是内存类参数先行、刷盘类次之、连接类兜底。模板往往隐含固定假设（例如 16C64G 配 SSD），照搬到小规格或混合盘机器上很容易翻车。正确做法是每次只动一组参数，压测对比后再决定是否上生产，并保留回滚记录。
基本信息
| 变更流程 | 备份现状、压测基线、单变量调整、再压测、滚动生效、观察一周 |
|---|---|
| 回滚前提 | 每次变更记录参数旧值 |
| 生效方式 | 动态用 SET GLOBAL，持久用 SET PERSIST，静态参数改配置并重启 |
| 模板假设 | 16C64G 加 SSD 的场景示例 |
| 核心参数 | 缓冲池大小、redo 容量、IO 能力、连接数 |
典型使用场景
- 新实例上线：以模板为起点做压测，确定最终值
- 硬件升级后复核：内存翻倍后缓冲池与 redo 容量需要重新评估
- 版本升级后复核：8.0.30 起 redo 参数入口变化
- 压测调优：固定其他条件只改一组参数，比较结果
- 巡检与配置基线比对：发现被临时改动却未回退的参数
- 排查突发性能下降：确认是否有人改过连接数或刷盘策略
my.cnf 参考模板
my.cnf 参考模板
[mysqld]
innodb_buffer_pool_size = 32G # 约物理内存的 50%
innodb_buffer_pool_instances = 8
innodb_redo_log_capacity = 4G # 8.0.30+ 的 redo 入口
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
max_connections = 1000
thread_cache_size = 64
table_open_cache = 4000
# 生效前先做语法检查：mysqld --validate-config
# 变更后核对：SELECT VARIABLE_NAME, VARIABLE_SOURCE FROM performance_schema.variables_info核心参数读法
| 参数 | 作用 | 调整影响 |
|---|---|---|
| innodb_buffer_pool_size | InnoDB 缓存池大小 | 偏小导致物理读升高，命中率下降 |
| innodb_redo_log_capacity | redo 总容量 | 偏小触发频繁 checkpoint，写入变慢 |
| innodb_io_capacity | 后台刷脏的 IO 能力估计 | 与磁盘实际能力不符会拖慢写入 |
| max_connections | 最大连接数 | 过大导致线程争抢，过小则连接被拒 |
| thread_cache_size | 空闲线程缓存 | 偏小造成连接建立开销上升 |
模板是 16C64G、SSD 的场景假设；照抄到 4C8G 或混合盘上会翻车。调参前先确认瓶颈在内存、IO 还是 SQL，再决定动哪个参数。
连接数不是越大越好：上限过高会让线程争抢 CPU 与内存，实践中常配合应用侧连接池与 thread_cache_size 一起收敛，而不是一味上调 max_connections。