企业选购计算实例时如何核对CPU、内存和磁盘IO，关键不是只看规格表上的数字，而是让候选配置承受接近真实业务的负载。以运行 MySQL 的业务数据库为例，查询速度变慢可能来自 CPU 排队、内存不足导致频繁读盘，也可能是磁盘随机读写延迟过高；三者要分别验证。
先把业务负载变成可比较的条件
采购前先整理高峰时段的并发请求、读写比例、常用查询、数据量和增长趋势。优先从现有监控或测试环境取数，不要用单一的“平均利用率”代表峰值。没有监控数据时，可用经过脱敏、结构相近的数据，在候选实例上重放典型查询或执行基准测试；测试期间保持数据量、并发数和软件配置一致。
记录每轮测试的吞吐量、响应时间及资源占用，并重复测试以识别偶然波动。测试数据应注明持续时间、并发设置和读写比例，否则不同实例的结果难以公平比较。采购判断还要考虑业务目标：短暂的资源尖峰，与持续数小时的高负载，对实例的要求并不相同。
CPU：看持续能力，不只看 vCPU 数
规格表中的 vCPU 表示可调度的虚拟处理器，不一定等同于独占的物理核心。还要查看实例是否为突发型、是否存在 CPU 积分或持续性能限制，以及处理器是否共享。突发型实例适合负载大部分时间较低、偶尔升高的应用；持续计算型配置更适合长时间高利用率的数据库任务，但通常应结合价格与业务时段评估。
用代表性查询或数据库基准测试逐步增加并发，观察 CPU 使用率、运行队列和响应时间。如果利用率长期接近满载且响应时间随并发明显上升，说明计算资源可能不足；若 CPU 不高但查询仍慢，应继续查内存和磁盘，不能直接靠增加 vCPU 解决。比较时同时记录测试期间的实例规格和可持续性能说明。
内存：关注工作集是否装得下
数据库内存不应按数据文件总量简单配置。对于 MySQL，重点核对缓冲池中的常用数据与索引能否得到有效缓存，同时给操作系统、连接、临时排序和后台任务留出空间。可观察内存占用、交换分区活动、缓存命中情况，以及高峰时是否出现明显的缺页或延迟上升。
选型时可把高峰稳定运行后的实际占用作为基线，并预留增长余量；约 20%–30% 可作为初步规划参考，而不是适用于所有业务的硬性标准。数据集增长快、并发连接多或查询临时空间需求大的场景，应通过压测修正。若发生持续换页，单纯增加 CPU 通常无助于解决瓶颈。
磁盘IO：拆开看延迟、IOPS和吞吐量
磁盘不能只比较容量。随机读写较多的数据库，要看 IOPS（每秒输入输出操作数）和 IO 延迟；大块顺序读写或备份任务，则更需要关注吞吐量。还应核实标称性能是否随磁盘容量、实例规格或队列深度变化，云平台的共享型与本地盘也可能有不同的持久性和故障处理方式。
测试时按业务的块大小、读写比例和并发度设置负载，并检查延迟分布，而非只看平均值。短测试可能反映不出持续写入后的性能变化；测试时长可从数分钟起步，并延长到覆盖实际高峰或后台任务的周期。使用 fio 等工具时，应避免对生产盘直接做破坏性写入；先在隔离测试盘验证参数。系统侧可结合 iostat 查看设备利用情况和等待时间。
采购前按同一套流程核对
选取至少一个业务高峰场景，记录并发量、读写比例、数据规模和可接受的响应时间。
筛选候选实例，确认 vCPU 的持续性能、内存规格、磁盘类型、IOPS及吞吐限制，并核实是否存在突发额度。
在相同软件与数据条件下分别测试 CPU、内存和磁盘，再运行完整业务负载，记录吞吐量、响应时间与资源曲线。
对比性能是否稳定、规格是否留有余量，以及扩容方式和磁盘持久性；不要只按峰值跑分或最低价格决定。
因此，企业选购计算实例时如何核对CPU、内存和磁盘IO，应以可复现的业务负载为依据：CPU看持续计算能力，内存看工作集与换页，磁盘看延迟、IOPS和吞吐。把测试条件和结果留档，再按瓶颈选择配置，通常比盲目增加规格更稳妥。
常见问题
实例标称的 IOPS 越高就一定越好吗？
不一定。若业务主要进行顺序读写，吞吐量可能更关键；若数据访问零散，随机IO的延迟和IOPS更值得关注。应按实际读写模式判断。
只看CPU平均利用率可以选型吗？
不够。平均值可能掩盖高峰，应同时看高峰利用率、运行队列和请求响应时间，并确认实例能否持续提供标称性能。
什么时候应该优先增加内存？
当工作集无法有效缓存、交换分区持续活动或内存压力与查询延迟同步上升时，应评估加内存；仍需通过对照测试确认效果。
短时间压测能代表长期表现吗？
未必。短测适合初筛，但持续写入、备份和高峰并发可能改变资源表现。最终测试应覆盖有代表性的业务时段，并记录测试条件。
