MySQL优化策论：隆中对·第二篇 硬件篇·硬盘·2·部署方略

康大头
67 阅读5分钟

2025-07-31 00:14·康大头

夫硬盘既辨，优劣已明，然知其然而不知其所以用，则犹得良马而不知驭之术，终难致千里。今承前论，续言部署之策，因材施器，因地制宜，方能各尽其能，固我数据库之基。

1、HDD部署策：集众为一，以阵法补其短

RAID（独立磁盘冗余阵列）是一种通过 组合多个物理硬盘，以提供 更高性能、数据冗余或两者兼具 的存储技术。常见的RAID类型有 RAID 0、RAID 1、 RAID 5、 RAID 10。

1.1、单盘HDD性能有限，然集多盘为阵，则可化零为整。

  • RAID 10：最佳之选。兼具条带化（提升读写）与镜像（冗余），随机读写性能较单盘大幅提升，且允许单盘故障而不失数据。

优点：读写均衡，容错性强，恢复相对简单。

缺点：成本翻倍（50%空间用于冗余），容量利用率低。

  • RAID 5/6：适合以容量为主、写入不频繁场景。通过奇偶校验实现冗余，

优点:空间利用率高

缺点：写入放大严重，重建过程耗时长，期间系统性能骤降，风险高。

1.2、分离关键文件路径

将 ibdata1（系统表空间）、ib_logfile*（redo log）、binlog 置于不同物理磁盘，减少磁头争抢，提升并发能力。

例子: 以MySQL 8为例 my.cnf 文件配置 假设路径/disk1 、/disk2 、/disk3 位于不同的硬盘

innodb_data_home_dir = /disk1/mysql/system
innodb_log_group_home_dir = /disk2/mysql/redo
log_bin = /disk3/mysql/binlog/mysql-bin
datadir = /disk4/mysql/data

1.3、适用团队

HDD虽可恢复性高，然重建耗时，风险隐伏，非精于存储者不能善后。

  • 团队有RAID管理与故障诊断能力
  • 团队有数据恢复协作能力
  • 团队有备份验证与快速恢复能力
  • 团队有I/O性能分析能力
  • 预算有限的初创团队 或 数据仓库/归档系统 团队。
  • 数据访问以顺序读写为主（如日志分析、报表查询），对延迟不敏感
  • 可接受较高恢复时间，重视数据可恢复性与长期存储成本

评曰：HDD如老将，非不可用，惟需以阵法统之。RAID为盾，调度为令，分路而治，方可缓其迟，增其力。

2、SSD部署策：养马有道，以节制延其寿

2.1、启用TRIM与合理预留空间（Over-Provisioning）

    • 在操作系统层启用 discard 或定期执行 fstrim，通知SSD哪些块已不再使用，提升垃圾回收效率。
    • 建议预留 10%-20%  的未分区空间，供SSD内部磨损均衡与写放大缓冲。优点：显著延长寿命，维持长期性能稳定。缺点：牺牲部分可用容量。

2.2、选择企业级SSD并监控健康状态

    • 消费级SSD耐写性差，应选用企业级SSD（如Intel DC系列、Samsung PM系列），具备更高P/E周期与断电保护。
    • 使用 smartctl 定期监控 Wear Leveling Count、Reallocated Sectors、Available Spare 等关键指标，预警潜在故障。

2.3、数据安全：备份为本，RAID为辅

    • SSD损坏后数据极难恢复，故备份是唯一可靠手段。
    • 建立完整备份策略：每日全备 + binlog增量，异地保存。可辅以 RAID 1 防单盘故障，但不可替代备份。
    • 注意：RAID 5/6在SSD上重建风险高，不推荐。

2.4、适用团队：

SSD一旦损坏，数据难寻，故“防”重于“救”，备份与监控乃生命线。

  • 团队要有，SMART监控与寿命预测能力
  • 团队要有，自动化备份与验证机制
  • 团队要有，快速切换与主从切换能力
  • 团队要有，文件系统与TRIM管理能力
  • 中大型互联网团队 或 高并发OLTP系统 团队。
  • 业务对响应延迟敏感，需稳定高IOPS。
  • 具备运维能力与监控体系，能实施自动化备份与健康巡检。
  • 愿为性能支付合理溢价。

评曰：SSD如良驹，日行千里，然不节其力，则中道而疲。TRIM为养，预留为空，监控为诊，备份为命，方能驰骋长久。

3、NVMe部署策：驭风而行，以精舍安其神

3.1、散热为先，环境为要

  • NVMe发热量大，须确保服务器风道畅通，优先安装于带散热片的插槽或U.2热插拔背板。
  • 可部署温度监控，超温降频将严重影响性能。

3.2、优化内核与文件系统参数

  • 使用较新Linux内核（≥4.4）以获最佳NVMe支持。
  • 文件系统建议 XFS，挂载选项可加 noatime,logbufs=8,logbsize=256k 提升日志性能。
  • 调整I/O调度为 none（即mq-deadline或none），NVMe自带高效队列，无需复杂调度。

3.3、高可用部署：NVMe + 复制架构

  • 单盘NVMe虽快，仍为单点。应结合MySQL Group Replication、InnoDB Cluster 或主从复制，实现数据冗余。
  • 可搭配 远程持久内存（如Intel Optane PMem）  作日志缓存，极致降低延迟。

3.4、适用团队

  • 团队要有，高性能环境监控能力
  • 团队要有，高可用架构运维能力(如: MySQL InnoDB Cluster、Group Replication 或 MHA)
  • 团队要有，极速恢复与冷备热备切换能力
  • 团队要有，硬件级故障排查能力
  • 头部互联网公司、金融核心系统 或 实时分析平台 团队。
  • 业务对极致性能与低延迟有刚性需求（如高频交易、实时推荐）。
  • 拥有高端服务器资源与专业DBA团队，能精细调优与监控。
  • 预算充足，追求技术领先性。

评曰：NVMe如飞将，一日千里，然非良厩不能久居。散热为厩，通道为道，复制为盾，方能纵横无碍，所向披靡。

4、择器如择将，用之在人

HDD、SSD、NVMe，各有所长，亦各有所短。
善用者，不在器之贵贱，而在谋之深浅。

  • 小国寡民，可屯HDD以守仓廪；
  • 中流砥柱，当驱SSD以御强敌；
  • 雄图霸业，必仗NVMe以争先机。

然无论何器，备份为基，监控为眼，架构为盾，此三者不立，则虽有千里马，亦将陷于险地。
故曰：硬件择优，部署为要；用之有道，方成大业。

avatar
文章
阅读
粉丝