判断云主机磁盘IOPS与吞吐量如何匹配数据库，不能只看磁盘标称的最高值。数据库可能同时受随机读写能力、连续传输速度和写入延迟限制；应先观察实际负载，再按读写模式配置。以下以常见的 MySQL/InnoDB 场景说明。
先分清 IOPS、吞吐量与延迟
IOPS 是每秒完成的磁盘读写次数，吞吐量是每秒传输的数据量。两者通过单次 I/O 大小关联：吞吐量约等于 IOPS × 单次 I/O 大小。例如，按 4 KiB 请求计算，1 万 IOPS 对应约 39 MiB/s；请求为 16 KiB 时，同样的 IOPS 则对应约 156 MiB/s。这里是理论换算，实际还会受到队列、文件系统和云盘限制影响。
随机小块访问常先碰到 IOPS 上限；大块连续读写则更容易先碰到吞吐量上限。数据库提交事务还关心写入延迟，尤其是需要等待日志落盘时：IOPS 和吞吐量够用，并不代表单次写入足够快。
按数据库工作负载选择侧重点
随机查询与索引访问
InnoDB 默认页大小通常为 16 KiB，但实际磁盘请求大小会受缓存命中、预读和存储栈影响。若查询大量读取分散的数据页、缓存命中率偏低，应优先关注随机读 IOPS 和读延迟。单纯提高顺序吞吐量，未必能改善这类查询。
事务日志与批量读写
事务日志通常以连续追加为主，但提交可能等待同步写入完成，因此要同时检查写入延迟与写 IOPS。备份、全表扫描或批量导入会产生较大的连续 I/O，更需要足够吞吐量。混合负载下，前台查询和后台任务会争用同一块盘，不能只依据单一任务的峰值选型。
| 观察到的瓶颈 | 优先调整方向 | 注意事项 |
|---|---|---|
| 随机读写次数接近上限 | 提高 IOPS 能力，或改善缓存命中率 | 检查延迟是否随队列增长 |
| 连续读写速度接近上限 | 提高吞吐量能力 | 确认单次 I/O 大小和任务并发 |
| 事务提交变慢 | 检查同步写延迟及日志盘负载 | 不要只看平均吞吐量 |
用监控和测试确定配置
选取有代表性的业务时段，记录读写 IOPS、吞吐量、平均及高分位延迟、队列长度和云平台的磁盘限额；同时观察数据库缓存命中、慢查询与事务提交时间。
区分业务高峰、备份和批量任务，确认瓶颈是否持续出现。Linux 上可用 iostat 观察设备利用率、队列和延迟，并结合云平台监控核对是否触及云盘限制。
用实测峰值估算配置，并预留约 30%—50% 的余量作为起点。余量不是固定标准；突发流量、业务增长和云盘是否采用突发额度都会改变需求。
在隔离的测试盘或业务副本上复现读写比例、块大小和并发度。可使用 fio 等工具做对照测试，但不要在生产数据盘上直接运行可能覆盖数据的测试。
调整后用相同业务负载复测，确认延迟、错误率和吞吐都改善；若性能在一段时间后下降，检查突发额度耗尽或共享资源争用。
配置判断与常见问题
云主机磁盘IOPS与吞吐量如何匹配数据库，最终要由业务请求大小和延迟目标决定：随机小 I/O 先看 IOPS，连续大 I/O 先看吞吐量，事务提交则重点核对写入延迟。不要把规格峰值当作长期可用性能。
只提高 IOPS，吞吐量会不会自动提高？
不一定。只有在请求大小不变且磁盘吞吐上限尚未触及时，增加 IOPS 才可能带来更高吞吐。
数据库磁盘利用率不高，为什么查询仍慢？
平均利用率会掩盖短时延迟和排队；还应查看高分位延迟、队列变化、锁等待和查询执行计划。
数据盘和日志盘要不要分开？
读写竞争明显、日志同步写影响事务时，可评估分盘；若负载较轻，分盘带来的管理复杂度未必值得。应在相同负载下测试再决定。