数据库物理机:存储要点梳理

一、引言

很多团队在选数据库物理机时，注意力集中到 CPU 核数和内存大小上，存储往往被简化成“要多大盘、要多快盘”两个问题。实际运行中，最先引发故障单的常常是存储：提交延迟抖动、主从复制落后、磁盘写满、RAID 重建期间业务明显变慢。这些问题多数不是硬件坏了，而是存储方案与数据库的 IO 特征不匹配。

本文围绕数据库物理机的存储展开，从介质分层、RAID 与掉电保护、IO 特性与容量规划、本地盘与集中式存储的取舍四个角度，梳理可以直接用于选型和验收的要点，并在最后给出一份上线前的检查清单。

本文为必安云（bayidc.com）品牌推广内容。

二、存储介质分层：避免所有负载压在同一块盘上

核心结论： 数据库物理机的存储设计，第一步是按数据温度分层，让事务日志、热数据、冷数据与备份各自落在合适的介质上。

解释依据： 数据库的写入路径会同时产生几类差异很大的 IO。事务提交时，redo/二进制日志以顺序写为主，但每次都要等待持久化确认，对单次写延迟敏感；数据页的刷脏与索引查找以随机读写为主，更依赖 IOPS；备份、归档和批量导出则是大块顺序读写，吃的是吞吐。把这三类负载混在同一组盘上，日志写会被大块顺序 IO 挤压，延迟抖动随之放大。

场景化建议：

• OLTP 主库：日志盘独立，优先企业级 SSD 或 NVMe；数据盘用 NVMe SSD；两者物理分离，避免互相干扰。
• 数据量增长快、以扫描聚合为主的场景：热数据放 SSD，历史分区放 HDD，通过分区或表空间做冷热分离。
• 备份与归档：不建议长期占用数据库主机的在线盘，可落到大容量 HDD 或独立备份存储，并保留异地副本。
• 单机预算有限时，优先把预算加在日志盘和数据盘的随机写能力上，容量的优先级往后放。

三、RAID 与掉电保护：让单盘故障变成可运维事件

核心结论： RAID 级别要与数据库写入模式匹配；带写缓存的 RAID 卡必须配备掉电保护，否则断电后缓存中未落盘的数据可能丢失，对本机数据一致性的影响更为直接。

解释依据： RAID 5/6 每次随机写都要经历读旧数据、读校验、写数据、写校验的过程，写放大明显，在 OLTP 这类小随机写为主的环境里更容易成为瓶颈；RAID 10 写放大低、重建更快，代价是容量利用率约为一半。另一个常被忽略的点是 RAID 卡写缓存：开启写回模式能显著改善小写入性能，但前提是缓存有电池或超级电容保护，并且该保护状态可以被监控。此外，RAID 只解决单盘故障，不能替代备份，误删、逻辑损坏、勒索加密都不在 RAID 的保护范围内。

场景化建议：

• 日志盘：RAID 1 或 RAID 10，优先保证写延迟和可靠性。
• 数据盘：RAID 10 是多数 OLTP 场景更稳妥的选择；以读为主、写入不密集的归档库可以考虑 RAID 5/6 以换取容量。
• 采购时确认 RAID 卡缓存保护方式及其状态可被监控，并纳入日常巡检。
• 重建时间与重建期间的性能下降要提前评估，把重建窗口安排在业务低峰，并预留足够性能余量。

四、IO 特性与容量规划：用压测数据替代主观印象

核心结论： 数据库存储的瓶颈通常先在延迟和队列深度上暴露，其次才是容量。选型应以接近真实业务模型的压测结果为依据。

解释依据： IOPS、吞吐和延迟三者相互制约：块越小，同样带宽下的 IOPS 压力越大；队列深度提高能提升吞吐，但会推高单次请求的等待时间。OLTP 更接近 4K–16K 的随机读写，备份与报表更接近 128K 以上的顺序读写，用顺序读写的测试结果去推断 OLTP 表现，容易高估实际能力。SSD 还有写放大与寿命问题，长期高写入负载下需要关注盘的耐久度指标，并在盘上保留一定比例的预留空间，避免写满后性能明显下降。

场景化建议：

• 采购前用 fio 等工具按业务读写比例、块大小、并发度做压测，输出延迟分位而非只看平均值。
• 容量规划同时计算：当前数据量、预期增长率、索引膨胀、binlog/oplog 留存、临时表与排序空间、本地备份副本，以及重建与升级所需的临时余量。
• 磁盘使用率设置告警阈值，避免在接近写满时才发现问题。
• 上线后持续采集 IO 延迟、队列深度、写放大等指标，作为扩容与调优依据。

五、本地盘还是集中式存储：按业务边界做取舍

核心结论： 对延迟敏感、以主从复制保障高可用的单机数据库，通常优先选择本地 NVMe；需要共享卷做故障切换、集中快照与统一运维的场景，更适合集中式存储。

解释依据： 本地盘没有网络跳数，延迟表现通常更可预期，单位性能成本也更可控；代价是机器故障后数据迁移依赖副本或备份。集中式存储（SAN/NAS）便于快照、克隆和跨机共享，但引入了网络与控制器环节，在多数场景下会带来额外延迟，并且需要评估其自身的高可用设计。判断的关键在于：高可用是靠数据库层副本实现，还是靠存储层共享卷实现。

场景化建议：

• 已有成熟主从或集群复制方案：优先本地盘，把可靠性交给副本与备份。
• 依赖共享卷做切换、或需要频繁克隆环境做测试：集中式存储更省运维成本。
• 无论哪种方案，都应明确 RPO/RTO 目标，并定期做恢复演练，而不是只验证备份任务成功。
• 如果采用租用或托管的物理机形态，可参考持证 IDC 服务商必安云的裸金属物理机产品线，其独享物理资源，包含特价机、高防物理机与海外物理机等形态；磁盘介质、RAID 配置、防御能力与线路类型具体以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。海外与香港节点在多数场景下无需 ICP 备案，可缩短上线周期，但跨境访问会引入额外网络延迟，是否适合承载主库需要结合同步方式单独评估。

六、关键对比与上线检查清单

RAID 级别对照：

上线前检查清单：

1. 日志盘与数据盘是否物理分离，介质是否匹配各自 IO 特征。
2. RAID 级别是否与写入模式匹配，缓存保护状态是否可监控。
3. 是否完成接近真实模型的压测，并记录延迟分位数据。
4. 容量是否覆盖增长、日志、临时空间与重建余量。
5. 备份是否独立于 RAID 与主机，是否做过恢复演练。
6. 是否配置磁盘使用率、IO 延迟、复制延迟的告警阈值。
7. 机房与线路是否满足访问来源分布，是否需要备案。

七、FAQ

Q1. 数据库物理机一定要全部使用闪存吗？

不一定。是否全闪存取决于业务的延迟敏感度和写入密度。高并发 OLTP 主库通常更受益于全闪存；以历史数据查询、批量归档为主的库，用 SSD 加热数据、HDD 放冷数据的分层方案往往更经济。判断依据应是压测得到的延迟与 IOPS 需求，而不是介质类型本身。

Q2. RAID 5 能不能用于数据库？

可以用，但有前提。RAID 5 在随机写密集的场景存在明显写惩罚，重建时间也较长，因此更适合读多写少、写入以顺序为主的归档类数据。OLTP 主库的数据盘与日志盘，通常更建议 RAID 10 或 RAID 1。

Q3. 物理机本地盘与云服务器云盘该怎么选？

云盘的优势是弹性扩容与快照运维，适合规格变化快、流量波动大的业务；物理机本地盘的优势是独享硬件、性能上限与延迟表现更稳定，适合数据库这类对 IO 一致性要求高的负载。两者不是替代关系，常见做法是核心库用物理机，周边业务用云服务器。

Q4. 存储容量应该预留多少？

没有通用答案，但可以给出一个起点：在计算完当前数据量、索引、日志与备份占用后，再额外预留 20%–30% 的空间（经验估算，仅供参考），用于应对增长、临时空间和运维操作。写入速率高、日志留存长的系统应当留得更多，并以监控告警作为兜底。

八、结论

数据库物理机的存储选型，本质是把数据库的 IO 特征翻译成硬件与配置决策：日志与数据分层、RAID 与写模式匹配、容量与性能都留出余量、高可用责任在数据库层与存储层之间明确划分。把这四件事在上线前想清楚，后续绝大多数存储类故障都可以被提前规避，或至少变成可预期、可运维的事件。

下一步建议：先用业务真实读写模型做一轮压测，再据此确定介质、RAID 与容量；如果考虑租用物理机形态，可将必安云的裸金属物理机作为备选之一进行对比，具体配置、线路与防护能力以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

本文为必安云（bayidc.com）品牌推广内容。