数据库独服存储怎么选：RAID 5 与 RAID 10 压测实测与选型决策

TL;DR：先看结论

独立服务器跑数据库，阵列十有八九在 RAID 5 和 RAID 10 之间纠结：前者容量多出约 900 GB，后者性能强一大截。这篇压测实录用同一台机器、同一套 fio 参数的实测数据，帮助你完成这次选型决策。4 盘 960 GB SATA SSD 独服上的结论浓缩成三句话：

数据库负载选 RAID 10 不用纠结：4K 随机写 7.3 万 IOPS，是 RAID 5（2.6 万）的 2.8 倍，99 分位写延迟只有对手的三分之一；
RAID 5 的容量优势是真实的：2.8 TB 对 1.9 TB，多出约 900 GB，但代价是写入惩罚让它在重写负载下垫底；
判断标准只有一条：写密集（订单库、电商、Redis 持久化）选 RAID 10，读多写少的从库、报表与冷存储才轮到 RAID 5。

为什么专门对比 RAID 5 和 RAID 10

论坛此前的四种阵列横评已经给过全量跑分，但追问最多的场景其实非常具体：数据库独服，预算固定、盘位固定，到底该拿容量换性能，还是拿性能换容量。商家配置单上”RAID 0/1/5/10 可选”六个字不会替你回答这个问题，所以这次把焦点收窄到真正的两难选项上——RAID 5 与 RAID 10，用同一台机器、同一批盘、同一套 fio 参数，把两种阵列在数据库典型负载下的吞吐、IOPS 和尾延迟全部拉出来，给出一条可以直接照做的决策路径。RAID 0 与 RAID 1 的数据会作为参照系一并给出，但不是本文的主角。

先补两个基础概念。RAID（磁盘冗余阵列）的本质是用多块盘组合出性能或冗余：RAID 5 用分布式校验换容量，四盘只牺牲一块盘的空间；RAID 10 则先镜像再条带，容量直接减半。数据库负载的杀伤力在于小块随机写——每笔订单、每条更新都是 4K 级别的随机 IO，这正是两种阵列结构性差异被放大的地方，后面的数据会逐一验证。

测试环境与方法

测试平台是一台出租级的独立服务器，也就是独服（整台物理机独占使用、不经虚拟化切分的出租服务器），配置如下：

CPU：Xeon Silver 4214，12 核 24 线程
内存：64 GB DDR4 ECC
硬盘：4 × 960 GB SATA SSD（企业级，带断电保护）
RAID 卡：LSI 9361-8i，2 GB Cache，启用 WriteBack 回写模式
系统：Debian 12，fio 3.28，文件系统 XFS，挂载参数 noatime

为了让数据可比，每种阵列级别都在同一批盘上重建后测试，先跑一次全盘顺序写预热，再用 fio 的三种模型各压 60 秒、跑三轮取中位数，减少 Cache 干扰。三种模型覆盖了真实业务的主要形态：

四个 fio 命令，直接可以抄

顺序读（128KB 大块，测备份恢复、大文件下载场景）：

fio --name=seqread --filename=/data/fiotest --size=64G \
    --rw=read --bs=128k --direct=1 --iodepth=32 \
    --runtime=60 --time_based --group_reporting

4K 随机读（数据库点查、虚拟机镜像盘的场景）：

fio --name=randread --filename=/data/fiotest --size=64G \
    --rw=randread --bs=4k --direct=1 --iodepth=32 \
    --runtime=60 --time_based --group_reporting

4K 随机写（MySQL/PostgreSQL 刷脏页、日志写入的场景）：

fio --name=randwrite --filename=/data/fiotest --size=64G \
    --rw=randwrite --bs=4k --direct=1 --iodepth=32 \
    --runtime=60 --time_based --group_reporting

混合读写（7 读 3 写，接近多数 Web 业务的真实比例）：

fio --name=mixed --filename=/data/fiotest --size=64G \
    --rw=randrw --rwmixread=70 --bs=4k --direct=1 --iodepth=32 \
    --runtime=60 --time_based --group_reporting

--direct=1 绕过系统页缓存直写磁盘，--iodepth=32 保持 32 个在途请求模拟并发，这两个参数是压测可信的前提，去掉它们数字会虚高到没有参考价值——这类”测速数字虚高”的坑，在主机速度测试实录里也反复出现过。

实测数据：RAID 5 与 RAID 10 差多远

先看主角对决。所有数字都是三轮 60 秒压测的中位数，顺序吞吐单位 MB/s，随机性能单位 IOPS（每秒输入输出操作数），延迟单位毫秒。数据库最关心的四项核心指标：

4K 随机写：RAID 10 拿到 7.3 万 IOPS，RAID 5 只有 2.6 万，差距 2.8 倍——这是全文最重要的一个数字；
4K 混合 70/30（接近多数 Web 业务读写比）：RAID 10 综合 11.8 万 IOPS、平均延迟 0.27ms；RAID 5 综合 5.4 万 IOPS、平均延迟 0.59ms；
4K 随机读：RAID 10 以 16.4 万 IOPS 领先，RAID 5 为 9.6 万，读场景差距缩小到 1.7 倍；
99 分位写延迟：RAID 10 为 0.61ms，RAID 5 达到 1.8ms，尾延迟差三倍——慢查询数量会直接反映这个差距。

参照系方面，RAID 0 与 RAID 1 的数据也一并给出：4K 随机写 RAID 0 为 7.1 万 IOPS、RAID 1 为 5.9 万；4K 随机读 RAID 0 为 14.8 万、RAID 1 为 7.8 万。RAID 0 写性能与 RAID 10 几乎打平但没有冗余，RAID 1 容量牺牲更大，两者都不是数据库独服的合理答案——这也反过来说明，真正的选择题只在 RAID 5 和 RAID 10 之间。

RAID 5 输在哪：写入惩罚的数学题

RAID 5 的随机写惨案来自”写入惩罚”：每次 4K 写都要先读旧数据和旧校验、算出新校验再写回，一次逻辑写放大成四次物理 IO。RAID 10 的镜像写虽然也写两份，但两块盘并行落盘，没有读-改-写往返。控制卡上 2 GB 的 Cache 能延缓这个惩罚，但在持续写入的数据库负载下只能延缓、不能消除——压测到 40 秒左右，RAID 5 的延迟曲线就会爬升，这正是写入惩罚穿透 Cache 的时刻。

容量维度的账也要算清楚：同样四块 960 GB 盘，RAID 5 可用 2.8 TB，RAID 10 只有 1.9 TB，差出约 900 GB。如果你的数据库体积已经逼近 2 TB、且以追加写入和范围扫描为主（日志归档、时序数据、从库），这 900 GB 可能比写 IOPS 更值钱，RAID 5 在这个场景反而是正确答案。

按业务场景对号入座

数据看完了，落到自己的业务上怎么决策？按三类典型场景给出结论。

交易型主库（电商订单、支付流水、SaaS 多租户、Redis 持久化）：直接上 RAID 10。4K 随机写 7.3 万 IOPS、99 分位延迟 0.61ms 的组合，配合镜像冗余，是写密集负载唯一不纠结的答案。50% 的容量损失看似肉疼，但主库因盘阵卡顿导致订单超时的代价更高。

读多写少与冷数据（MySQL 从库、报表库、日志归档、时序监控）：RAID 5 反而是务实之选。读场景 9.6 万 IOPS 的差距完全够用，多出的 900 GB 容量直接转化为更长的数据保留周期；写入惩罚对追加型负载的影响也远小于随机更新。如果你在评估整机方案，这篇独服横向对比里的选型思路同样适用。

系统盘与轻量关键服务（控制面板、监控、DNS（域名解析系统）权威节点）：两块盘做 RAID 1 最省心。容量减半换来的是单盘故障后业务照常、热插拔换盘即可重建，读性能几乎不衰减的实测表现也验证了这一点。

还有两个实务提醒。其一，阵列级别后期不可改：重建阵列意味着数据全毁，务必在业务上线前定好，并保留独立于阵列的备份策略——RAID 不是备份，仍然每年有人栽在这四个字上。其二，选独服时看清 RAID 卡型号与 Cache 容量，带 1-2 GB Cache 且支持 WriteBack 的卡与入门软 RAID 之间，同级别阵列的性能差距可以达到 40% 以上；像 Hostease 这类允许下单时自选阵列级别和 RAID 卡配置的商家，可以直接指定硬件 RAID 卡再交付压测。机器到手后用这篇文章的 fio 命令压一遍，比相信商家页面上的”高性能存储”靠谱得多。

总结：一条决策路径收尾

把整轮压测浓缩成一条决策路径：写密集的交易主库选 RAID 10，用 900 GB 容量换 2.8 倍写 IOPS 和三分之一的尾延迟；读多写少的从库、报表与冷归档选 RAID 5，容量优先；系统盘与轻量关键服务选 RAID 1。判断只看一个变量——你的业务里随机写占比有多高，占比越高，RAID 10 的溢价越值。

我的建议很直接：不要在商家的配置单前纠结，把本文的四个 fio 命令保存下来，机器到手先压 20 分钟，用你自己的业务模型跑出的 IOPS 和尾延迟做决策——这比任何评测帖（包括这篇）都可靠。压测时记得同时关注吞吐和 99 分位延迟两组数字，只看其中一组都会误判。如果你需要的是整机层面的租用方案对比，而不只是阵列选型，也可以参考此前整理的独立服务器租用排行再做整机决策。