公司动态 · 发布时间：
数据库每秒处理几万条请求，不等于磁盘需要几万IOPS：缓存命中、事务日志和后台刷新都会改变实际磁盘读写。要做好云端实例磁盘IOPS与数据库读写负载匹配，应从数据库产生的物理I/O出发，而不是直接用业务QPS推算。
先区分IOPS、吞吐量与延迟
IOPS表示每秒完成的读写操作数；云盘吞吐量表示每秒传输的数据量；存储延迟则反映单次I/O要等待多久。三者相关，但不能互相替代。随机小块读写常受IOPS和延迟影响，备份、全表扫描等连续读写则更容易触及吞吐量上限。
例如，假设实测平均I/O大小为8 KiB、磁盘负载为每秒1万次操作，理论数据量约为78 MiB/s。若平均I/O变为16 KiB，同样的IOPS对应的数据量约翻倍。实际值还会受读写比例、缓存、存储规格和计量方式影响，因此选盘时要同时核对IOPS和云盘吞吐量上限。
用数据库实测值估算需求
看物理I/O，不要把SQL请求数当成磁盘操作数
PostgreSQL、MySQL等数据库会利用内存缓存数据页；一次查询可能不触发磁盘读取，而一次事务也可能带来数据页写入和日志写入。可在代表性业务时段查看数据库与操作系统的磁盘读写指标，区分读、写、平均块大小及高峰变化。监控周期应覆盖日常高峰；若业务存在周末批处理或月末作业，也要纳入观察。
按峰值留余量，再检查延迟
分别记录读IOPS和写IOPS，关注持续高峰及短时尖峰，并查看P95或P99存储延迟。在实测峰值上预留约20%至30%作为初始余量，是常见的估算起点，不是所有负载都适用的固定比例；增长快、波动大或延迟要求严格的业务应结合容量计划增加余量。若IOPS尚未达到上限但延迟明显升高，还需排查队列、吞吐量限制和共享存储争用。
按负载特征选规格
| 负载特征 | 优先核对 | 适用考虑 |
|---|---|---|
| 随机小块读写频繁 | IOPS上限、读写延迟 | 优先比较性能型云盘或可配置IOPS的持久化云盘；成本通常较高，需确认是否能稳定提供目标性能。 |
| 大块连续扫描或备份 | 吞吐量上限、IO大小 | 高IOPS未必解决带宽瓶颈；应确认磁盘与实例两侧的吞吐量限制。 |
| 写入密集且日志频繁 | 写IOPS、日志延迟 | 检查事务日志与数据写入是否争用同一卷；拆分存储可能改善隔离，但会增加配置和维护复杂度。 |
| 低成本、可重建数据 | 数据持久性与恢复方式 | 本地临时盘可能有较好的性能特征，但生命周期和故障保护因云平台而异，不宜在未确认恢复方案时存放唯一数据副本。 |
按步骤验证配置
- 采集基线：在正常高峰和批处理时段记录物理读写IOPS、平均I/O大小、吞吐量及延迟，避免只观察数据库连接数或SQL QPS。
- 计算峰值需求：将读写分开评估，并对比业务峰值、持续时长和增长趋势。用实测数据估算吞吐量：IOPS乘以平均I/O大小；同时确认云盘与实例规格均未形成更低的上限。
- 核对规格边界：比较不同云盘档位的性能上限、是否支持单独配置IOPS、性能是否受容量影响，以及是否存在突发额度或共享限制。具体规则以所选平台和规格说明为准。
- 做接近生产的验证：在测试环境使用相似的数据规模、读写比例和并发模式进行压测，覆盖随机读、随机写及必要的连续操作；同时观察延迟是否满足应用要求。不要仅凭短时峰值判断持续性能。
- 上线后复核：持续检查高峰期间的IOPS、吞吐量、队列深度和延迟。若IOPS余量充足而吞吐量贴近上限，应优先排查大块读写；若队列持续升高且延迟恶化，则需复核存储规格、实例限制与并发写入。
常见问题
IOPS买得越高，数据库一定越快吗？
不一定。若瓶颈在CPU、内存缓存、锁竞争或吞吐量，单独提升IOPS未必改善响应时间。应先依据指标定位限制项。
能用数据库QPS直接换算IOPS吗？
通常不能。QPS是应用或数据库请求量，缓存命中率、每次请求访问的数据页数及日志写入都会影响物理I/O，应以磁盘实测为准。
数据盘和日志盘要分开吗？
当日志写入与数据读写互相争用、且指标能证实延迟受影响时，可评估分卷隔离。分开后仍要检查实例总IOPS和总吞吐量限制，避免把瓶颈移到实例层。
归根结底，云端实例磁盘IOPS与数据库读写负载匹配要同时满足操作数、数据传输量和延迟要求。先采集真实物理I/O，再按峰值选型并压测，通常比单看标称IOPS更可靠。
