参数调优：Buffer Pool、redo 容量与连接数清单

默认参数的潜台词

装完 MySQL 直接上线，是很多项目的第一课学费。默认参数的设定哲学是「在什么硬件上都别崩」，不是「在你这台机器上跑最快」。这篇把最值得调的几个参数讲透，也给一份「别乱动」的红线清单。

命根子：Buffer Pool

InnoDB 的读写都在内存的 Buffer Pool 里进行（第 7 篇的 WAL 就是把随机写攒在这里缓冲），命中了内存就省一次磁盘 I/O。Buffer Pool 大小是单机性能的第一变量：

# 经验：专用数据库服务器给物理内存的 50% - 70%
# 32G 内存 → 20G 上下；太满挤掉 OS 与其他进程，太小命中率高不了
innodb_buffer_pool_size = 20G
innodb_buffer_pool_instances = 8    # 大于 1G 时拆多实例，减少锁竞争

衡量标准是命中率：SHOW GLOBAL STATUS LIKE "Innodb_buffer_pool_read%"，读命中/(读命中+未命中) 在 99% 以上算健康，持续低于 95% 就是容量不足或冷数据太多。热库比缓存更有价值——能全放进去就别省。

redo 容量：checkpoint 的节拍器

第 7 篇讲过 redo 循环写：write pos 追上 checkpoint 就得先刷脏页腾地方——redo 太小，高峰期会周期性停下来刷脏，写入曲线呈锯齿状抖动。8.0.30 起 redo 相关参数合并为 innodb_redo_log_capacity（旧的 innodb_log_file_size × innodb_log_files_in_group 的组合退役）：

# 经验起点：按高峰一小时写入量给；写入密集业务 4G-8G 不嫌大
innodb_redo_log_capacity = 8G

连接数：一道数学题

max_connections = 1000          # 允许的最大连接
# 配套的线程缓存，短连接场景减少线程创建开销
thread_cache_size = 64

max_connections 常被当成越大越好的勋章，错了。每个连接对应一个线程，活跃连接过多会引发上下文切换风暴——CPU 全忙着切换，真干活的时间反而变少。正确的算法是：应用侧各连接池上限之和（第 16 篇讲池子怎么配）再留 10-20% 余量给运维直连，1000 的 max_connections 配 200 个真实并发，比 10000 配 2000 个健康得多。另外记得给超级用户预留连接（默认 SUPER 保留一个，8.0 还提供 admin_address 管理通道），不然连接打满时你连上去救火都进不了门。

I/O 侧的两个旋钮

• innodb_io_capacity / innodb_io_capacity_max：告诉 InnoDB 磁盘多能刷——SSD 给 2000/4000 起步，机械盘 200/400。给低了刷脏太保守，给高了挤占业务 I/O；
• innodb_flush_neighbors = 0：SSD 没有机械寻道问题，关掉相邻页刷新这个机械盘时代的优化。

别乱动的红线清单

• innodb_flush_log_at_trx_commit 与 sync_binlog：交易链路双 1 别动（第 10 篇）；
• sort_buffer_size、join_buffer_size：这些是每连接分配的会话级缓冲，全局调大会在连接多时内存爆炸；优先治让排序溢出的 SQL，别调大缓冲；
• query_cache：8.0 已整个移除，别再网上抄老博客调它；
• 每次只改一两个参数：改前记录原值、改后观察命中率与吞吐曲线，一把梭会让你永远不知道是谁起了作用。

参数给了池子和管道，但「现在系统哪里不对劲」还是要靠工具回答——performance_schema 和 sys schema 就是 MySQL 自带的体检仪，下一篇实战。

咖啡凉了，记得趁热喝。