数据库越跑越卡，问题往往不在 CPU
数据库独服越跑越卡，如何判断瓶颈在磁盘而不是 CPU？一位站长的遭遇很有代表性：租了台四盘位独立服务器（独服，即整台物理机独享资源的租用形式）跑 MySQL，上线三个月订单高峰期频繁卡顿，CPU 和内存占用却只有三成。最后的排查结论是机房默认装的 RAID 5 阵列随机写太弱，数据库的写入请求全在排队。这篇文章就教你用 fio 把 RAID 0、RAID 1、RAID 5、RAID 10 四种配置逐一压一遍，帮你解决”磁盘是不是瓶颈”的定位难题，而不是反复加内存碰运气。与常见的阵列参数科普不同，本文全程围绕”排查卡顿”这条主线：先给方法，再看数据，最后落到怎么选。
测试平台是 4 块同型号 960GB 企业级 SATA SSD，阵列卡开启直通缓存策略，操作系统层面统一关闭预读干扰项，保证数据可比。fio（Flexible I/O Tester，Linux 下最常用的磁盘压测工具）是这次的主力工具，下面先交代测试方法，再看数据。
压测方法：四组 fio 命令，覆盖两类典型负载
每次重建阵列后，都跑同样的四组场景：1M 顺序读、1M 顺序写、4K 随机读、4K 随机写。前两组模拟备份、大文件分发这类流式负载；后两组模拟数据库、邮件队列这类小块高频负载。每轮测试跑 120 秒并重复两次取均值，避开首次写入的缓存抖动。
顺序读测试命令：
fio --name=seqread --rw=read --bs=1M --numjobs=4 --iodepth=32 \
--direct=1 --size=64G --runtime=120 --group_reporting \
--filename=/dev/md-test --ioengine=libaio
4K 随机写测试命令：
fio --name=randwrite --rw=randwrite --bs=4k --numjobs=4 --iodepth=32 \
--direct=1 --size=64G --runtime=120 --group_reporting \
--filename=/dev/md-test --ioengine=libaio
这里有两个参数最容易被新手忽略：--direct=1 绕过系统页缓存，测出来的才是磁盘真实能力；--iodepth=32 模拟多任务并发，单队列深度下的数字对数据库场景几乎没有参考价值。曾有社区网友用默认参数测出”SSD 比 NVMe 还快”，多半就是缓存没有绕开。
实测数据：四种阵列的真实表现
同一台机器、同一批盘，四次重建阵列跑出的均值如下，带宽（磁盘每秒吞吐的数据量）单位为 MB/s，IOPS（每秒输入输出操作数）衡量随机性能：
| 阵列配置 | 顺序读 | 顺序写 | 4K 随机读 | 4K 随机写 |
|---|---|---|---|---|
| RAID 0（4 盘条带） | 1840 MB/s | 1710 MB/s | 236K IOPS | 96K IOPS |
| RAID 1（2 盘镜像） | 510 MB/s | 495 MB/s | 88K IOPS | 82K IOPS |
| RAID 5（3+1 校验） | 1320 MB/s | 640 MB/s | 171K IOPS | 31K IOPS |
| RAID 10（2+2 镜像条带） | 920 MB/s | 880 MB/s | 182K IOPS | 89K IOPS |
几个直接结论：RAID 0 的顺序读接近单盘的四倍，条带并行收益肉眼可见，但任何一块盘故障全阵列报废，生产环境不建议裸奔。RAID 5 的随机写只有 31K IOPS，是四组里最刺眼的数字——每次写都要回写校验，小块写被放大成接近四次磁盘操作，MySQL 这类写密集场景会明显吃亏。RAID 10 的随机写 89K IOPS，接近 RAID 5 的三倍，这也是数据库服务器几乎清一色选 RAID 10 的原因：可用容量减半，换来写入不衰减和双盘容错的底气（不同时坏在同一镜像组内）。
RAID 1 看起来最”慢”，但它的 88K 随机读和 82K 随机写差距极小，读写最均衡，系统盘、轻量业务盘用两块小盘做 RAID 1，性价比其实很高。
按业务选阵列：数据库、文件站与建站场景
数据看完了，落到自己的业务上怎么选？先看写入特征，再看容量预算。
- 数据库、电商订单、社区论坛：写密集且要求故障可继续运行，首选 RAID 10。89K 的随机写 IOPS 足够支撑每秒数千笔订单落盘，这类业务的选购思路可以参考我们之前整理的《美国独立服务器性价比评估的五个指标》，磁盘子系统往往才是真正的瓶颈。
- 图片站、下载站、视频分流：大文件顺序读写为主，容量敏感，RAID 5 或 RAID 6 更划算。校验带来的写入惩罚对顺序大块影响有限，3+1 结构下可用容量有 75%，比 RAID 10 的 50% 多出一半。
- 企业官网、外贸站群：读写均衡、数据量不大，两盘 RAID 1 即可，省下的预算放到内存和 CDN（内容分发网络，通过边缘节点加速静态资源）上，对页面加载的改善更直接；站群该用 VPS（虚拟专用服务器，从物理机切分出的独立资源块）还是独服（整机独享的物理服务器），可参考《香港云主机 VPS 与独立服务器对比》。
顺带一提，RAID 不等于备份。阵列只解决单盘故障的连续性问题，误删、勒索加密、机房级灾难都要靠异地备份兜底，这点在《GPU 实时推理延迟与吞吐评测》里提到的”压测数据要落到真实容灾方案”是同一个道理。
下单前问清楚：容易被忽略的三个细节
理论选型之外，实际下单时还有三个细节最容易踩坑。第一，问清阵列是硬 RAID 还是软 RAID：软 RAID 依赖 CPU 计算校验，重建阵列时业务性能可能掉一半以上；有阵列卡缓存的硬 RAID 在随机写下优势明显。第二，确认阵列卡电池/电容状态，写缓存依赖 BBU 供电，失效后阵列卡会自动降级为 Write-Through，写入性能可能直接腰斩。第三，SSD 阵列要确认是否支持 TRIM，长期不支持 TRIM 的阵列会因盘内无用块回收效率下降而越用越慢。
以 Hostease 的美国独服为例，下单时可以直接和客服确认阵列卡型号、缓存策略与硬盘是否支持热插拔，这些配置比多几十 GB 内存更影响长期体验；预算接近时，也可以对比一下各家的 NVMe 方案，参考《美国主机隐藏配置项与 NVMe、CPU 线程实测》再决定。
总结：一张表记住怎么选
回到最初的问题：同样的四块盘，选错阵列，数据库随机写可能差三倍。这次压测的结论可以浓缩成三句话：追求极限性能且能接受风险，才考虑 RAID 0；容量优先的文件类业务，RAID 5 是平衡点；凡是跟钱和数据有关的业务，直接上 RAID 10 不纠结。
建议你拿到新服务器后，别急着跑业务，先用本文的 fio 命令压 10 分钟，把四种负载的基线数据存档——机器超售、降配或阵列策略不对，都能在第一时间暴露。如果你正在对比各家独服的存储方案，推荐从 RAID 10 的随机写表现这一项切入筛选，这是最能区分供应商真实水平的指标。
