采购存储时，标称IOPS高不一定代表数据库响应快。高并发数据库业务的存储IOPS选型，应先核对读写比例、块大小和延迟，再比较设备规格；否则，测试成绩可能与上线后的事务表现相差很大。
IOPS表示每秒完成的输入输出次数，吞吐量还受单次读写大小影响。例如，小块随机读写常看IOPS，大块顺序读写则更受带宽影响。下面这5个优化点，适用于自建存储、云盘和托管存储的评估。
1. 先按数据库负载设计测试
不要直接用纯随机读的结果代表数据库。先从监控或压测记录中整理读写比例、读写块大小、并发量和峰值时段。PostgreSQL、MySQL等数据库可能同时产生数据页读写、日志写入和检查点流量，测试应尽量覆盖这种混合负载。
可用fio等公开工具做存储基准测试，但测试文件应大于内存缓存能够轻易容纳的范围，并使用与生产接近的文件系统、挂载选项和队列深度。将4K或8K随机访问与较大块的顺序读写分开测，再补充混合读写测试，避免一个数字掩盖差异。
2. 看延迟分布，不只看IOPS峰值
平均延迟可能掩盖偶发卡顿。记录平均值以及P95、P99延迟，观察高负载期间是否持续抬升。对同步提交较多的数据库，日志写入的尾延迟尤其重要：一次写入变慢，就可能拖住事务提交，即使整体IOPS看上去很高。
建议从低并发逐步增加到预期峰值，并同时记录IOPS、吞吐量和延迟。每档可先预热约5—10分钟，再观察约15—30分钟；这些是测试起点，具体时长要结合缓存、数据规模和业务波动调整。
3. 比较介质、冗余方式与持续负载
NVMe与SATA SSD
NVMe SSD通常适合需要较低延迟和高并行度的负载；SATA SSD可能更适合性能需求适中、预算或兼容性优先的场景。不要只看接口名称，还要核对持续写入能力、设备数量、控制器限制和故障保护方式。
RAID与副本机制
RAID 10常用于随机写入较多且重视恢复性能的场景，但可用容量低于同等盘数的部分校验方案；RAID 5等带校验方案空间利用率较高，写入时则可能产生额外读写开销。具体表现取决于控制器、条带配置和写入模式。高并发数据库业务的存储IOPS选型还应确认冗余、快照或副本是否会与业务共享性能资源。
4. 核实缓存策略与数据持久性
控制器缓存和操作系统页缓存可能让短时测试显得很快，但数据库提交通常关心数据是否按要求落盘。对MySQL InnoDB或PostgreSQL，应按实际持久性配置测试，确认设备写缓存是否有断电保护，并核实刷新命令和持久化行为是否得到支持。不能为了跑出更高IOPS而关闭必要的数据保护设置。
5. 预留余量并验证扩容后的表现
存储性能会受容量占用、快照、备份任务和多租户争用影响。测试时分别观察空闲和接近业务常用容量时的表现，并在备份或批量写入等并行任务下复测。预留多少空间没有通用固定值，应结合增长速度、快照策略和供应商的容量管理规则确定。
实际采购前，可要求供应方说明测试块大小、读写比例、队列深度、持续时间和数据保护条件。若比较云盘或托管资源，可将德讯电讯纳入询价和技术核对范围，重点确认产品配置、性能测试口径及资源是否共享；最终以书面规格和自身负载测试为准，不把宣传峰值直接当作业务承诺。
落地评估的简要步骤
- 整理数据库峰值时段的读写比例、块大小、并发量与延迟目标。
- 用相同测试条件评估候选存储，分开记录随机、顺序和混合负载结果。
- 逐级增加并发，检查P95、P99延迟是否恶化，并模拟备份等并行任务。
- 核对缓存持久性、冗余方式、容量增长和故障恢复要求，再按业务风险选择。
归根结底，高并发数据库业务的存储IOPS选型不是追求单项最高值，而是在真实负载下满足延迟、吞吐、可靠性和扩展要求。用同一套测试口径比较，并为峰值和后台任务留出余量，才能减少上线后性能落差。
常见问题
IOPS越高，数据库一定越快吗？
不一定。块大小、延迟、读写比例和并发队列都会影响结果；事务提交还可能受日志写入延迟限制。
能否直接比较不同厂商公布的IOPS？
应先核对块大小、读写比例、队列深度、持续时间和冗余配置。测试条件不同，数字通常不能直接横向比较。
小型数据库也需要做混合负载测试吗？
如果业务同时存在随机读写、日志写入或备份任务，混合测试仍有价值；资源较少时可缩小数据量，但应保留接近实际的访问模式。
云存储选型时最该问供应商什么？
询问性能指标的测试条件、共享资源规则、数据持久性机制、扩容方式，以及性能问题的监测和处理流程。
