没有“最强性能参数模板”，真正决定mysql性能的是数据访问模式、写入频率、连接行为和磁盘i/o能力；盲目套用24g buffer pool或4g日志文件易致启动失败、内存抖动甚至实例挂死。
直接说结论：没有“最强性能参数模板”这回事，盲目套用 24G Buffer Pool 或 innodb_log_file_size=4G 反而容易引发启动失败、内存抖动甚至实例挂死。 真正决定性能上限的，是你的数据访问模式、写入频率、连接行为和磁盘 I/O 能力——不是配置文件里某几行数字的大小。
innodb_buffer_pool_size 不要直接设为 24G
很多教程说“32G 机器给 MySQL 24G”，但这个值在 16 核 32G 的真实环境里常出问题。原因有三：
- Buffer Pool 描述块（per-page metadata）会额外吃掉约 5%~8% 内存，24G 配置实际可用缓存页可能只有 ~22.5G，且大块连续内存分配失败概率上升
- Linux 内核对大页（
innodb_buffer_pool_chunk_size）的默认策略可能不匹配，导致启动时卡在Initializing buffer pool, total size = 25600 MB, instances = 8, chunk size = 128 MB - 如果系统还跑着 Prometheus、Logstash 或容器运行时，OS 缓存和 page cache 会被严重挤压，反而加剧 swap 使用
实操建议：
- 先确认空闲内存：
free -h看available值，不是free；再减去其他服务常驻内存（如 Java 应用 RSS） - 初始值建议从
innodb_buffer_pool_size = 18G起步，观察 24 小时内Innodb_buffer_pool_pages_free是否长期 > 1000 - 若命中率
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)持续 > 99%，且Innodb_buffer_pool_wait_free≈ 0，再每次 +2G 迭代
innodb_buffer_pool_instances 必须匹配 NUMA 架构
16 核服务器大概率是双路 CPU（2×8），即两个 NUMA node。若 innodb_buffer_pool_instances 设为 1 或 16，会导致跨 NUMA 访存加剧、锁竞争升高，SHOW ENGINE INNODB STATUS\G 中能看到明显 buffer pool mutex waits。
实操建议：
- 查 NUMA topology：
numactl --hardware，看有几个 node - 每个 node 分配 2~4 个 instance，16 核常见配法是
innodb_buffer_pool_instances = 8（2 node × 4） - 必须配合
innodb_buffer_pool_chunk_size = 128M（MySQL 5.7+ 默认），否则实例数变更后重启会报错Buffer pool size can't be changed
innodb_log_file_size 别只盯吞吐，要看 crash recovery 时间
设成 2G 或 4G 确实能降低 checkpoint 频率，但 recovery 时间会线性增长。一次主库宕机后，mysqld 启动卡在 Recovering from log file ./ib_logfile0 半小时，比慢查询更致命。
实操建议：
- 用
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written'查每小时日志写入量，取 3 小时峰值 × 2 作为目标值 - 例如一小时写 3GB，则
innodb_log_file_size = 2G（两文件共 4G）较稳妥；超过 6G/小时才考虑 4G 单文件 - 修改前必须停库、删旧日志、更新配置、再启库；否则报错
Invalid log file size直接无法启动
max_connections 和 thread_handling 容易被高估
看到“16 核”就设 max_connections = 8000 是典型误区。MySQL 线程模型不是核数线性扩展的：每个连接至少占 256KB~1MB 内存（取决于 sort_buffer_size 等），8000 连接光线程栈就吃掉 8GB+，还没算连接本身开销。
实操建议：
- 先查当前峰值：
SHOW GLOBAL STATUS LIKE 'Threads_connected';和历史监控中Max_used_connections - 生产环境建议按公式估算：
max_connections = min(2000, 当前峰值 × 1.5)，留 buffer 给突发流量 - MySQL 5.7+ 推荐关闭
thread_cache_size（设为 0），改用thread_handling = pool-of-threads（需启用thread_pool_size = 16）来压降上下文切换
真正卡住性能的，往往不是某个参数没调到最大，而是 innodb_old_blocks_time 还在默认 0（导致热点数据被冷数据刷出）、tmp_table_size 和 max_heap_table_size 不一致引发隐式磁盘临时表、或者 query_cache_type = 1 在高并发下制造全局锁。这些细节不检查，光调 buffer_pool_size 就像给轮胎打气却不看胎压表——气越足，爆得越快。
