存储介质选型必须用fio做贴近真实业务的基准测试，关键在于测出目标场景下的真实能力边界：数据库重iops与99%尾延迟，文件服务器重顺序吞吐，虚拟化重混合负载；测试前须确认对象层级、是否直通缓存及数据量与预热。
存储介质选型不能只看厂商标称参数，必须用 FIO 做贴近真实业务的基准测试。关键不是“跑出多高数字”，而是测出它在你目标场景下的真实能力边界。
明确你要测什么场景
不同业务对 I/O 的需求差异极大：
-
数据库（如 MySQL、PostgreSQL）：重点关注 4K 随机读写 IOPS 和延迟，尤其是 99% 尾延迟（latency clat 99.0%）。建议用
rw=randread/randwrite、bs=4k、iodepth=32~128、numjobs=4~8 -
文件服务器或备份归档：侧重顺序吞吐，用大块（
bs=1M或64k）、rw=read/write，观察带宽（MB/s）是否达标 -
虚拟化平台（如 KVM、VMware datastore）：推荐混合负载测试，例如
rw=randrw+rwmixread=70（7 成读、3 成写），bs=8k~16k，模拟多虚机并发访问
测试前必须确认的三件事
避免测了白测，先核对这三点：
-
测试对象层级：是裸盘（
/dev/nvme0n1）、LVM 卷、RAID 阵列，还是云硬盘/网络存储（如 NFS/Ceph）？不同层性能表现不同，结论不能跨层比较 -
是否绕过缓存：生产环境多数应用不依赖系统 page cache，所以务必加
--direct=1；若想测含缓存表现（如某些缓存型应用），可设--direct=0，但需注明 -
数据量与预热：SSD/NVMe 测试前要预热（先跑一轮随机写），否则首测结果偏低；
--size建议 ≥ 设备写缓存容量（NVMe 通常 1–4GB），或直接设为50G~100G确保稳定
FIO 关键参数组合建议
以下命令模板可直接复用，已适配主流 SSD/NVMe 场景：
-
4K 随机读（数据库 OLTP 场景）：
fio --name=randread_4k --filename=/dev/nvme0n1 --rw=randread --bs=4k --iodepth=64 --numjobs=4 --runtime=120 --direct=1 --ioengine=libaio --group_reporting -
1M 顺序写（大文件导入/日志落盘）：
fio --name=seqwrite_1m --filename=/dev/sdb1 --rw=write --bs=1M --iodepth=16 --numjobs=2 --size=50G --direct=1 --ioengine=libaio --group_reporting -
混合读写（虚拟机通用负载）：
fio --name=mixed_8k --filename=./testfile --rw=randrw --rwmixread=70 --bs=8k --iodepth=32 --numjobs=4 --runtime=180 --size=20G --direct=1 --ioengine=libaio --group_reporting
结果怎么看才不被误导
别只扫一眼 “IOPS=120K” 就下结论，重点盯这几个字段：
-
IOPS：对应
io=xxxKiB/bs，比如io=49152KiB、bs=4k→ IOPS = 49152 / 4 = 12288 - 带宽（bw）：单位是 KiB/s 或 MiB/s，反映实际吞吐能力
-
延迟分布：关注
clat percentiles中的 95% 和 99%，例如99.00th=[1250us]表示 99% 的请求完成时间 ≤ 1.25ms；超过 10ms 就可能影响交互体验 - 抖动（stddev）：clat 标准差太大（如 >30% 均值），说明延迟不稳定，不适合低时延敏感业务
