MySQL性能提升首选硬件升级，关键在NVMe SSD、充足内存（Buffer Pool占60%–75%）、平衡CPU主频与核心数，并优化网络与RAID配置。
MySQL性能提升，硬件是基础。光靠参数调优或SQL优化，遇到瓶颈时往往收效有限；换对硬件，效果立竿见影。关键不是堆配置，而是找准MySQL最敏感的几个硬件环节：磁盘I/O、内存容量、CPU并发能力与网络延迟。
优先升级SSD，尤其是NVMe协议的固态盘
MySQL是I/O密集型应用，尤其是InnoDB引擎的redo log写入、buffer pool刷脏页、查询时的随机读，都极度依赖磁盘响应速度。传统SATA SSD比机械硬盘快5–10倍，而NVMe SSD（如PCIe 4.0）随机读写IOPS可达百万级，延迟低至百微秒级，能显著降低锁等待和事务提交延迟。
- 建议使用本地直连NVMe盘，避免走网络存储（如NAS/NFS），否则网络延迟反而成为新瓶颈
- 将innodb_log_file_size设为单个log文件2GB以上（配合足够内存），减少日志轮转频率，发挥SSD持续写优势
- 数据目录、redo log、binlog尽量放在同一块高性能SSD上；若条件允许，可分离——redo log放低延迟小盘，数据文件放高吞吐大盘
内存要够大，且优先保障InnoDB Buffer Pool
Buffer Pool缓存数据页和索引页，命中率直接决定物理I/O次数。当Buffer Pool小于热数据集时，频繁换页导致大量磁盘读，性能断崖式下降。
- 生产环境建议Buffer Pool占物理内存的60%–75%，例如64GB内存服务器，可设innodb_buffer_pool_size = 48G
- 启用innodb_buffer_pool_instances（建议设为CPU核心数或8–16之间），减少内部争用
- 避免与其他内存大户（如Redis、Java应用）共用同一台机器；若必须共存，需严格限制其内存上限
CPU核心数与主频要平衡，别只看核数
MySQL单个连接多数时间串行执行（尤其复杂查询、锁竞争场景），高主频对单线程响应更友好；但并发连接多、复制线程多、后台刷脏页/ purge线程忙时，核心数又变得关键。
- OLTP类业务（高并发短事务）：优先选中高主频（≥3.0GHz）、16–32核的CPU，如Intel Xeon Silver 4310或AMD EPYC 7313
- OLAP或混合负载：可倾向更多核心（32–64核），但需确认MySQL版本支持良好（MySQL 8.0+对多核调度优化明显）
- 关闭CPU节能模式（如Intel SpeedStep、AMD Cool’n’Quiet），保持稳定主频；BIOS中开启NUMA balancing（若多路CPU）并合理绑定mysqld进程
网络与RAID不是次要项，该精简就精简
即使单机部署，网卡和存储控制器也影响稳定性与吞吐。很多“慢查询”实际源于底层设备响应抖动。
- 禁用RAID卡电池写缓存（BBU）失效时的自动降级模式，避免突发写入卡顿；若用软件RAID（mdadm），建议RAID 10而非RAID 5/6
- 数据库服务器网卡至少10GbE，关闭TCP offloading（如TSO、LRO），减少内核协议栈开销
- 不推荐虚拟化环境跑核心MySQL实例；若必须，确保vCPU直通、磁盘使用virtio-scsi + iothread、内存锁定（memlock）开启
硬件优化不是一步到位，而是结合业务特征逐步调整。先测I/O瓶颈（用iostat -x 1看await、%util、r/s w/s），再看内存压力（free、vmstat），最后分析CPU调度（pidstat -u 1）。换硬件前，务必做基线对比测试——同一SQL在旧/新环境下的QPS、平均延迟、99分位延迟，才是真实依据。
