在 CentOS 或 Ubuntu 上部署 MySQL(尤其是生产环境),强烈推荐使用 SSD(或云服务商提供的高性能 SSD 云盘,如 AWS gp3/io2、阿里云 ESSD、腾讯云 CBS SSD)而非普通机械式云盘(HDD 类型云盘)。原因如下:
✅ 核心原因:MySQL 是 I/O 密集型应用
MySQL(尤其 InnoDB 引擎)的性能高度依赖磁盘 I/O:
- 随机读写性能关键:索引查找、事务日志(
ib_logfile*)、缓冲池刷脏页、UNDO/REDO操作大量涉及 4K–16K 随机 I/O; - HDD 随机 IOPS 通常仅 ~100–200,而主流 SSD 云盘可达 3,000–50,000+ IOPS(ESSD AutoPL/gp3 可弹性调整);
- 延迟差异巨大:HDD 平均随机延迟 ≈ 10–20ms,NVMe SSD 可低至 0.1ms,云 SSD 通常 0.5–2ms —— 直接影响 QPS、TPS 和响应时间。
📊 对比简表(典型生产场景)
| 特性 | 普通云盘(HDD 类型) | SSD 云盘(推荐) |
|---|---|---|
| 随机 IOPS(4K) | 100–300 | 3,000–50,000+(可配置) |
| 平均延迟 | 10–30 ms | 0.5–2 ms |
| 吞吐量(顺序读) | ~100 MB/s | 200–1000+ MB/s |
| MySQL 表现 | 高并发下明显卡顿、慢查询频发 | 稳定高吞吐,支持千级 QPS+ |
| 适用场景 | 仅限测试、低负载、归档库 | 所有生产环境、主库、从库、高可用集群 |
⚠️ 注意事项(避免“假 SSD”陷阱)
- 确认是真 SSD,非“SSD 缓存盘”或“混合盘”
- 云厂商部分“SSD”产品实为 HDD + SSD 缓存(如某些入门级云盘),I/O 突发后性能骤降。务必选择明确标注 “全闪存”、“NVMe”、“ESSD”、“io2/gp3” 的类型。
- 合理配置 IOPS/吞吐配额(云盘需显式设置)
- 如 AWS gp3:默认 3,000 IOPS / 125 MB/s,可按需提升(最高 16,000 IOPS / 1,000 MB/s);
- 阿里云 ESSD:选择
PL1/PL2/PL3,PL3 支持最高 1,000,000 IOPS;
→ MySQL 生产库建议至少 3,000+ IOPS 起步,高并发建议 5,000+。
- RAID 与文件系统优化(物理服务器场景)
- 若自建物理服务器:用 NVMe SSD + RAID 10(非 RAID 5) + XFS 文件系统 +
noatime,nodiratime,barrier=0(谨慎)挂载选项; - Linux 内核参数调优:
vm.swappiness=1,vm.dirty_ratio=30,vm.dirty_background_ratio=5等(配合innodb_io_capacity设置)。
- 若自建物理服务器:用 NVMe SSD + RAID 10(非 RAID 5) + XFS 文件系统 +
✅ 最佳实践建议
| 场景 | 推荐方案 |
|---|---|
| 生产主库 / 高并发业务 | 高性能 SSD 云盘(ESSD PL2/PL3、gp3 with burstable IOPS、io2 Block Express) + 单独挂载 /var/lib/mysql 分区 |
| 从库 / 只读分析库 | 中等性能 SSD(如 ESSD PL1、gp3 默认配置) |
| 开发/测试环境 | 可用普通云盘(但建议仍用入门级 SSD,成本差异小,体验更真实) |
| 备份存储 | 可用低成本对象存储(OSS/S3)或 HDD 归档盘(与数据库盘分离) |
🔧 部署小贴士(CentOS/Ubuntu)
# 1. 挂载 SSD 云盘(假设设备为 /dev/vdb)
sudo mkfs.xfs -f /dev/vdb
sudo mkdir -p /data/mysql
sudo mount -o noatime,nodiratime,logbufs=8 /dev/vdb /data/mysql
# 2. 修改 MySQL 配置(/etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf)
[mysqld]
datadir = /data/mysql
innodb_data_home_dir = /data/mysql
innodb_log_group_home_dir = /data/mysql
innodb_io_capacity = 2000 # 设为云盘 IOPS 的 50%~70%
innodb_io_capacity_max = 4000
innodb_flush_method = O_DIRECT # 关键!绕过 OS cache,SSD 更高效
✅ 总结
选 SSD 不是“锦上添花”,而是 MySQL 生产部署的底线要求。
普通云盘(HDD)会导致严重 I/O 瓶颈,引发连接堆积、慢查询、主从延迟、甚至服务不可用。云厂商的 SSD 云盘性价比已极高(如阿里云 ESSD PL1 仅比 HDD 贵 20–30%,性能提升 20 倍+),不建议在任何有实际流量的 MySQL 生产环境中使用 HDD 类型存储。
如需进一步帮助(如具体云平台选型对比、MySQL 参数调优清单、备份策略),欢迎补充你的场景(例如:预计 QPS、数据量、是否主从、云服务商),我可以提供定制化建议。
CDNK博客