垂直扩展是通过增强单台服务器硬件（CPU、内存、磁盘、网络）提升 MySQL 性能，适合中等规模或短期瓶颈场景；需合理配置 innodb_buffer_pool_size、分离 IO 路径、启用大页内存、调优日志参数并持续监控验证。
垂直扩展是提升 MySQL 性能最直接的方式之一，核心思路是通过增强单台服务器的硬件能力（CPU、内存、磁盘、网络）来承载更高负载。它不改变架构，实施快、运维简单，适合中等规模业务或短期 性能瓶颈 场景。
升级 CPU 和内存
CPU 和内存对 MySQL 的并发处理能力和缓存效率影响显著。InnoDB 缓冲池（innodb_buffer_pool_size）建议设置为物理内存的 50%–75%，但需预留足够内存给 操作系统 和其他进程（如连接管理、排序、临时表）。高并发读写时，更多 CPU 核心可提升线程并行处理能力，尤其在执行大量 JOIN、GROUP BY 或事务密集型操作时效果明显。
- 检查当前缓冲池命中率：SHOW STATUS LIKE ‘Innodb_buffer_pool_%’;，关注 Innodb_buffer_pool_read_requests 与 Innodb_buffer_pool_reads 的比值，低于 99% 说明内存不足
- 避免盲目堆核数：MySQL 单实例对超多核（如 >32）的利用率可能受限于锁竞争或调度开销，建议结合压测验证收益
- 启用大页内存（Huge Pages）可降低 TLB 压力，需操作系统配合配置（vm.nr_hugepages）并启动时加 –large-pages
更换高性能存储设备
磁盘 I/O 是 MySQL 瓶颈高频区域，尤其是写密集或刷脏页压力大的场景。传统 HDD 已难以满足现代业务响应要求。
- 优先选用 NVMe SSD，随机 IOPS 可达 HDD 的百倍以上，显著缩短 redo log 写入、binlog 刷盘、checkpoint 和 buffer pool 刷脏时间
- 将 data directory、redo log、binlog 分离到不同物理设备（至少不同挂载点），减少 IO 争用；例如 redo log 放高速小容量盘，数据目录放大容量 NVMe 盘
- 确保文件系统启用 noatime 和 barrier=0（仅限有掉电保护的 SSD），并使用 XFS（比 ext4 更适合大文件和高并发）
优化 MySQL 配置适配新硬件
硬件升级后若沿用旧配置，无法释放全部性能潜力，必须同步调优关键参数。
- innodb_buffer_pool_instances：设为 CPU 核数的 1/4–1/2（上限 64），避免缓冲池全局锁争用；例如 16 核建议设为 4–8
- innodb_log_file_size：增大可减少 checkpoint 频率，提升写吞吐；建议总日志容量为 1–2 小时写入量，通常单个 1–4 GB（需停机调整）
- innodb_flush_log_at_trx_commit：生产环境默认为 1（强一致性），若允许短暂 数据丢失 风险，可设为 2（每秒刷一次 OS cache）换取显著写性能提升
- 适当提高 max_connections 和 table_open_cache，但需结合内存预留评估，避免 OOM
监控与验证不可少
垂直扩展不是“换完就完”，必须通过持续监控确认收益并识别新瓶颈。
