mysql性能提升首选硬件升级，关键在 NVMe SSD、充足内存（Buffer Pool 占 60%–75%）、平衡 CPU 主频与核心数，并优化网络与 R ai D 配置。
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）并合理绑定mysql d 进程
网络与 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 分位延迟，才是真实依据。
