主机参数表上的峰值 IOPS，不等于数据库上线后的稳定表现。评估数据库主机采购前的IOPS与并发压测清单，应把存储负载、数据库行为和业务并发放在同一套测试计划里；否则容易买到单项指标漂亮、实际查询却卡顿的配置。
先避开这5个压测误区
误区一：只测顺序读写
数据库的数据页常涉及小块随机读写，事务日志则更关注持续写入和落盘延迟。只跑顺序吞吐测试，无法代表这两类负载。至少分别测随机读、随机写、混合读写，并补测同步写入相关延迟。
误区二：把峰值 IOPS 当成长期能力
短测可能受到控制器缓存、主机内存缓存或存储突发机制影响。测试文件应明显大于可用内存，并运行到稳定阶段；可先预热 5—15 分钟，再连续观察 20—60 分钟。具体时长要结合存储缓存、数据规模和采购验收要求调整。
误区三：只改变并发，不记录延迟
并发提升时，吞吐量可能继续增加，但排队也会拉高响应时间。除 IOPS 和吞吐量外，同时记录平均延迟、P95 延迟、CPU 利用率、队列深度及错误数。若吞吐增长很小而 P95 明显恶化，继续加并发通常没有实际收益。
误区四：把 fio 结果当成数据库成绩
fio适合比较存储路径，却不模拟 SQL、索引、锁竞争和事务提交。应先用 fio 做分层筛查，再在目标数据库上做事务测试。PostgreSQL 可用 pgbench，MySQL 可用 sysbench；两者的测试模型和配置不同，不宜直接横向比较结果。
误区五：测试环境与计划部署不一致
磁盘数量、文件系统、RAID 或存储池设置、数据库版本、内存及电源策略都会改变结果。测试机应尽量复现计划部署环境；若不能，必须逐项记录差异，不能把实验室数据直接当作交付承诺。
按清单执行：从底层到真实事务
- 固定条件。记录 CPU、内存、磁盘型号与数量、控制器设置、文件系统、数据库版本及固件信息；确认测试卷没有其他负载。
- 做存储筛查。使用 fio 在专用测试文件上测试随机读、随机写和混合读写，块大小可从 4K、8K、16K 等常见档位开始，队列深度与并发数按预期负载逐级增加。不要直接对含有数据的裸设备写入。
- 跑数据库事务。准备与实际工作集规模相近的数据，逐步增加连接数，例如从 1、2、4 开始，再按业务预期扩展；每档运行到结果稳定，记录事务吞吐、延迟分位数、锁等待和磁盘写入情况。
- 重复并留档。至少在相同条件下重复测试，注明预热时间、持续时间、并发数和数据集大小。采购比较时逐项对照，不只取最好的一次。
IOPS 不是越高越好：低队列深度下的延迟更能反映少量活跃事务的体验；高并发结果则更适合观察主机饱和点。若启用缓存或写回策略，还要确认断电保护与持久化配置，否则测试成绩可能建立在不同的安全假设上。
验收时看组合，不设通用及格线
没有适用于所有数据库的固定 IOPS 门槛。应先从现有业务监控或容量规划中取得峰值并发、读写比例、数据集大小和可接受延迟，再设定采购目标。比较主机时，重点看目标负载下的稳定吞吐、P95 延迟、错误与超时，以及持续运行后是否降速。最终的数据库主机采购前的IOPS与并发压测清单，应包含测试条件、指标原始记录、重复结果和验收阈值；这样才能复核差异，而不是只比较宣传页上的单一数字。
常见问题
fio 的测试文件要多大？
应足以降低缓存对结果的影响，通常设置为明显大于可用内存；还要确认测试卷有足够空间，避免影响系统和数据库文件。
并发数应该测到多少？
从低并发逐级增加，覆盖预期业务峰值及合理余量；当延迟明显超出目标、错误增加或资源饱和时，记录该拐点即可。
IOPS 高但数据库慢，先查什么？
检查延迟分位数、队列深度、CPU、锁等待、缓存命中率和日志落盘情况。IOPS 高并不代表每次请求都足够快。
两个品牌的压测结果能直接比较吗？
只有测试数据、软件版本、存储配置和并发模型一致时才有参考价值；条件不同，应先消除差异再比较。