云服务器硬盘怎么选？容量、类型与 IOPS 三个变量拆开看

打开一个服务器产品的价格表，第一眼看到的往往是「核数、内存、硬盘、带宽」四列。而这四列里，只有一列的差异能到两个数量级——硬盘。20G 到 9.8T，差 500 倍；而核数最多差 10 倍、内存最多差 60 倍。这个悬殊的比例说明：硬盘是四列里唯一「按需买就行」的一项，也是最容易被买错的一项。这篇讲清硬盘的三个变量——容量、类型、IOPS——以及为什么「容量大」经常不等于「能用」。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	核心特点
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	三项都在合理区间的入门档
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	硬盘 30G 加 CN2 回国线路
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	每核 8.6 元，带宽需单独确认
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	480G 硬盘是整机档里少见的大盘
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	唯一「大端口配大配额」的组合

一、硬盘的三个变量

还有一个「第四个变量」很少被提：「是不是本地盘」。

本地盘装在宿主机上，网络盘通过网络挂载。

而两者的延迟差五到十倍。

而产品页上通常只写「SSD」，不写「本地还是网络」。这个差别对数据库业务是决定性的——同样标 SSD，本地盘的查询延迟可能是网络盘的五分之一。所以「SSD」这两个字在产品页上几乎没有区分度。

判断方法：看延迟的稳定性。

本地盘波动小，网络盘波动大。

再看一个「本地盘」的代价。

本地盘不能跨机器共享。

所以「多机部署」必须用网络盘或者分布式存储。

而这个限制决定了架构选择。

还有一个「云盘」的常见误解。

「云盘」不等于「SSD」。

因为云盘可以是 HDD 池，也可以是 SSD 池。

所以「云盘」这个说法只说明「不本地」，不说明「快」。

这一点在选型时要问清。

「500G 硬盘」这句话，实际包含三个独立的变量。

变量	决定什么	产品页写不写
容量	能存多少	一定写
类型	随机读写快慢	偶尔写
IOPS 配额	并发读写能力	几乎从不写

这张表最该注意的是第三行：IOPS 配额决定了「多个人同时读写时会不会卡」，而它几乎从不公布。

这个缺失的后果很具体：两个容量相同、类型相同的硬盘，一个给 3000 IOPS，一个给 500 IOPS，在「单用户」场景下完全一样，在「数据库」场景下差六倍。所以「500G SSD」这五个字，对数据库业务来说信息量是不足的——它没说「能不能扛住并发读写」。

第二行类型。「SSD」这个词也被用得很泛。

SATA SSD、NVMe SSD、网络盘的性能差三到五倍。

而产品页通常只写「SSD」，不写接口。

所以「同样是 SSD」，实际性能可能差好几倍。

第一行容量。这是唯一「确定」的变量。

所以「容量够不够」这个问题最好回答，「性能够不够」最难回答。

而选型时恰恰是后者更容易出问题。

三个变量的判断顺序：先看容量（硬门槛），再看类型（性能量级），最后看 IOPS（并发能力）。

而这三步只有第一步能从产品页完成。

二、容量：最确定也最容易算错

容量这块还有一个「文件系统开销」。

ext4 的元数据和保留块约占 5%。

所以「100G 的盘，实际可用 95G」。

这个开销在小盘上更明显——20G 的盘可能只剩 18G。所以要精确算「能存多少」时，这个 5% 要算进去。而这个细节在「刚好够用」的场景下很关键。

判断方法：df -h 看 Avail 列，不看 Size 列。

再看一个「inode 耗尽」的问题。

大量小文件会耗尽 inode，而不是耗尽空间。

而inode 满了之后，即使硬盘还有空间也写不进去。

所以「存大量小文件」的场景要检查 inode 使用率。

而这个检查很多人不知道，但一条命令就能看出来。

而<'数脉科技'+'> 那条 1T 档如果跑的是「海量小文件」业务，inode 数量就得先确认。

还有一个「扩容」的实际限制。

不是所有产品都支持「原地扩容」。

有的加盘可以，有的要换机型。

所以「能不能扩容」要比「现在够不够」更重要。

容量看起来最简单，但实际最容易算错。

因为「买多大」不等于「能存多少」。

系统与软件占 5G 到 10G，日志每月占 1G 到 5G，临时文件、备份、缓存各占一部分。

所以「20G 硬盘」的实际可用通常是 12G 到 14G；「50G」的实际可用是 40G 左右。而这个「可用率」在容量小时最刺眼——20G 的机器损失 35%，200G 的机器只损失 3%。所以小容量档位要特别留意这一点。

算「需要多大」的公式：

容量 = 系统 10G + 数据量 + 日志（每月 3G × 保留月数）+ 余量 30%。

举例：数据 20G、日志保留 3 个月，则 10 + 20 + 9 = 39G，加余量约 51G。

所以该买 50G 以上。

而这个算法比「凭感觉买」精确得多。

再看一个「容量增长」的问题。

数据是会增长的，所以「现在够用」不等于「半年后够用」。

而扩容通常比换机便宜。

所以「按两年后算」是个务实的默认值。

而<'zji'+'> 那种 480G 硬盘的整机档，正好适合「数据会长、但不想频繁换机」的场景。

还有一条「容量与备份」的关系。

备份需要的容量通常等于「数据量」，而不是「总容量」。

所以「500G 硬盘」的备份需求可能是 20G。

这个区别能省下不少备份成本。

三、类型：SSD 不是一种东西

类型这块还有一个「混合」的坑。

「SSD 缓存 + HDD 存储」的混合方案，性能取决于「缓存命中率」。

而命中率取决于「热数据能不能装进缓存」。

所以混合方案的性能是「不稳定的」——热数据命中时接近 SSD，未命中时退回到 HDD。而厂商宣传通常只提「SSD 加速」，不提「命中率低时怎样」。所以看到混合方案，要问「缓存多大」和「命中率多少」。

判断方法：跑 fio 测两轮，一轮读「刚写过的数据」，一轮读「很久没动的数据」。

两轮差很多，说明缓存占比大。

再看一个「SSD 寿命」的问题。

SSD 有写入寿命（TBW）。

而「频繁写入」的业务会更快消耗寿命。

所以「日志盘用 SSD」要谨慎。

而<'景文互联'+'> 那条 500G SSD 档，如果用来跑「高写入」业务，寿命是个要算的成本。

还有一个「TRIM」的问题。

TRIM 没开会让 SSD 越用越慢。

所以装好机器后要确认 TRIM 是否启用。

而这个检查一条命令就能做。

第二层是硬盘类型，它决定「随机读写」的量级。

HDD：4K 随机读延迟 5 到 10ms。

SATA SSD：0.5 到 1.5ms。

NVMe SSD：0.1 到 0.3ms。

这三档的差距是「几十倍」。而对数据库业务来说，这个差距直接体现为「查询快慢」。所以「同样的配置、同样的容量」，用 HDD 和 NVMe 的体验完全是两个量级。而这个差别在产品页上往往只差一个词，或者根本看不出来。

判断方法：装好机器后跑 fio 测 4K 随机读。

fio --name=randread --ioengine=libaio --rw=randread --bs=4k \
    --numjobs=1 --size=256M --runtime=60 --time_based --iodepth=32 --direct=1

判读要点：看平均延迟。

低于 0.5ms：NVMe 级别。

0.5 到 2ms：SATA SSD 级别。

超过 5ms：HDD 或严重争抢。

再看一个「类型与用途」的匹配。

数据库、容器、虚拟机：必须 NVMe 或高配额 SSD。

文件存储、备份、归档：HDD 够用。

网页文件：SATA SSD 够用。

三类用途对应的成本差五到十倍。

所以「买对类型」能省不少钱。

而<'数脉科技'+'> 那条 1T 硬盘的独服线，就是「容量优先、类型次要」的典型——适合归档，不适合数据库。

还有一个「类型与价格」的反常。

同样 500G，SSD 版本可能比 HDD 版本贵三倍。

而这不是「商家黑」，是成本差异。

所以「为什么这个贵」这个问题，答案往往在类型上。

四、IOPS：最看不见的限制

IOPS 这块还有一个「读写不对称」。

大多数盘的「写 IOPS」远低于「读 IOPS」。

而产品页通常只写一个数。

所以「3000 IOPS」可能是读的，写的可能只有 1000。而对「写多读少」的业务（日志、采集），这个差别很关键。所以问 IOPS 时要问「读写分别是多少」。

判断方法：fio 分别测随机读和随机写。

差异大，说明是「读优化」的盘。

再看一个「IOPS 与块大小」的关系。

「IOPS」通常按 4K 块算。

而1M 的大块读写，IOPS 会低得多但吞吐高。

所以「IOPS 高」和「吞吐高」是两回事。

音频、视频类业务看吞吐。

数据库类业务看 IOPS。

这一点在测试时要分开测。

还有一个「突发 IOPS」。

部分产品允许「短时超过配额」。

所以「测速时很快、跑久了变慢」是正常现象。

而这个特性对「偶尔批量」的业务有利。

第三层是 IOPS 配额，它是三者里最容易被忽略、也最容易出问题的。

IOPS 是「每秒能做多少次读写」。

而共享存储的 IOPS 是有限的，多台虚拟机一起用会互相争抢。

这个限制的表现很隐蔽：单用户测试时很快，多用户并发时突然变慢。而它不会被误判成「磁盘问题」，而会被误判成「服务器卡」——因为用户只感觉到「页面加载慢」，不知道是磁盘在排队。所以「磁盘 IOPS」这一项，值得在买之前问清。

判断方法：问「IOPS 是固定值还是按容量比例」。

固定值：明确知道上限。

按容量比例：加容量就能加 IOPS。

两种模式的差别很大。

而「按容量比例」的模式下，『加硬盘』等于『加性能』。

所以「磁盘慢」的解法可能是「加容量」而不是「换机器」。

再看一个「IOPS 需求」的估算。

一个中型 MySQL，峰值可能需要 2000 到 5000 IOPS。

而一个静态网站只需要几十 IOPS。

两者的需求差两个数量级。

所以「我的业务需要多少 IOPS」这个问题，答案取决于「业务类型」。

还有一条：「IOPS 与延迟」不是一回事。

IOPS 高不代表延迟低。

因为队列深度大的时候，IOPS 高但每个请求要等更久。

所以「看 IOPS 还要看队列深度」。

而这个细节在测试时很容易忽略。

五、容量与性能的取舍

取舍这块还有一个「成本曲线」的问题。

从 20G 到 100G，每成本下降得很快。

而从 1T 到 9.8T，每成本下降得慢。

所以「买大盘」的规模优势在小容量段最明显。而这个曲线的形状意味着「20G 档的单位成本最高」——所以只要能加到 50G，就应该加。而这个判断和「按需买」的原则并不冲突，因为 50G 本身就在「够用」的范围内。

判断方法：把「容量 ÷ 价格」算出来，看曲线形状。

陡降段，值得加。

平缓段，按需即可。

再看一个「分层」的实际成本。

系统盘 50G SSD + 数据盘 1T HDD，总成本可能低于「500G SSD」。

而这个组合性能反而更好。

所以「分层」不只是性能优化，也是成本优化。

而<'sixtynet'+'> 那种 Storage 档的存在，本质就是「把分层做成产品」。

还有一个「分层」的维护成本。

两块盘要自己管「什么放哪」。

而这个管理成本在小业务上不明显，在复杂业务上很明显。

所以「分层」要配合「自动化的数据放置策略」。

实际选型时，容量和性能往往不能同时满足。

大容量通常意味着 HDD（便宜但慢）。

高性能通常意味着小容量（NVMe 贵）。

所以「1T SSD」这种组合是稀缺的、也是贵的。而大多数业务实际需要的是「小容量高性能 + 大容量低性能」的组合——系统盘用 SSD，数据盘用 HDD。而这个分层能同时满足「快」和「大」，成本只有「全 SSD」的几分之一。

判断方法：看数据「访问频率」。

热数据（经常读）：SSD。

冷数据（很少读）：HDD。

而这个分层在单机上可以用「两块盘」实现。

而<'景文互联'+'> 那条产品线里，同为 500G 的 SSD 版本比 HDD 版本贵了三倍——这个差价就是「分层」的经济学依据。

再看一个「分层」的实际配置。

系统盘 50G SSD + 数据盘 1T HDD。

这个组合能同时满足「启动快」和「存得多」。

而成本比「1T SSD」低得多。

所以「两块盘」往往比「一块大盘」更合理。

还有一条：「日志盘」最好单独一块。

因为日志是「持续写入」，和数据读写抢 IOPS。

而分开之后，两者的干扰会明显减少。

再给一个「完整算例」，把三个变量串起来。

业务：一个含图片的内容站 + 一个小型数据库。

数据量：图片 30G（年增 15G），数据库 8G（年增 4G）。

访问：图片读多写少，数据库读多写多。

按两年算：图片需要 60G，数据库需要 16G，加系统 10G 和日志 6G，总计 92G，加余量约 120G。类型上，数据库要 SSD（随机读写），图片可以 SATA SSD 或 HDD。所以合理配置是「系统 50G SSD + 数据 70G SSD」，或者「系统 50G SSD + 图片 100G HDD + 数据库 20G SSD」。

两种方案的价格差可能三倍，而性能差别只在「图片读取快慢」上。所以「分层」这件事，本质是「按访问频率分配预算」。

而这个推演比「买最大的」精确得多。

再看一个「算例」的边界。

上面的「年增 15G」这个假设很关键。

如果实际增长更快，两年后就不够。

所以「增长率」这个参数要实测，不能估。

而<'云途'+'> 那种「20G 硬盘」的入门档，配的正是「数据量很小、增长很慢」的业务。

还有一条：「硬盘容量」这件事，宁可一次买够。

因为「扩容」往往比「多买」麻烦。

而这个规律在「数据只增不减」的业务上尤其成立。

还有一个「硬盘与备份」的联动。

备份方案的成本，取决于「数据量」而不是「总容量」。

所以「500G 硬盘但只用了 60G」的业务，备份成本按 60G 算。

而这个区别能让备份成本降一个量级。

而这一点常被忽略——很多人按「总容量」估备份，结果发现「买 500G 的盘，备份 500G」纯属浪费。所以「备份按实际数据量算」是个能省钱的默认做法。

判断方法：看「已用空间」，不看「总容量」。

再看一个「快照」的容量占用。

每次快照都会占用额外空间（存储改动的块）。

所以「频繁快照」会吃掉不少容量。

而这个占用在产品页上完全看不到。

所以「快照策略」要和「容量规划」一起考虑。

而<'isvoro'+'> 那种「硬盘 30G」的档，快照策略就要设得保守——否则空间很快被快照吃掉。

还有一条：「日志轮转」是硬盘的保命措施。

不配轮转，日志能把盘写满。

而盘满之后服务直接挂，且从外部看不出原因。

所以「装完机器第一件事配 logrotate」是个好习惯。

而这个动作花不了五分钟。

再补一个「硬盘与数据库」的配对问题。

数据库对硬盘的要求，和「文件存储」完全不同。

文件存储要「吞吐」，数据库要「IOPS 和延迟」。

所以「一个 1T HDD 能存很多文件，但跑不动数据库」。

而反过来，「一个 100G NVMe 跑数据库很快，但存不了多少文件」。所以「数据库和文件存储」应该分盘，甚至分机器。而这个分层在成本上也是划算的——用便宜的大盘存文件，用贵的 SSD 跑数据库。

判断方法：看「读写模式」。

大量小随机读写，要 SSD。

少量大顺序读写，HDD 也行。

而这个判断比看容量有用得多。

而<'zji'+'> 那种 480G 硬盘的整机档，如果跑数据库，要确认它是 SSD 还是 HDD——这个答案决定了它能不能用。

再看一个「硬盘与内存」的关系。

内存够大时，硬盘的读压力会降低（缓冲池）。

所以「加内存」能部分替代「换 SSD」。

而这个替代有上限——内存再大也挡不住「首次读取」。

所以「内存和硬盘」要一起看。

还有一条：「硬盘满了」这件事有前兆。

使用率到 80% 就该处理。

而到 90% 时很多服务会开始出问题。

所以「80% 告警」是个必要的监控项。

最后补一个「测试方法」的细节。

测硬盘性能要「在真实数据量下测」。

因为「空盘」和「80% 满」的性能不一样——尤其是 SSD，写满之后会变慢。

所以「用空盘测出很快」不代表「用起来也快」。

而这个细节在验收时经常被忽略。

还有一条：「顺序读写」和「随机读写」要分开测。

两者差一个数量级。

而只测一个就下结论，容易误判。

再提醒一句：「硬盘容量」要在「下单前」确认「能不能加盘」。

因为很多档位「加盘要换机型」。

再有：「SSD 和 HDD」的价格比大约五到十倍。

所以「买 SSD 还是 HDD」的决策，价值等于「五倍的差价」。

而这个决策只需要问一句「业务吃随机读写吗」。

还有：「硬盘」这一项的验收最容易被跳过。

因为「能启动、能写入」看起来就是好的。

而实际性能要跑 fio 才知道。

所以验收清单里应该有 fio，不只是「能不能连上」。

六、硬盘选型的三个结论

三个结论，按重要性排。

第一：容量按「两年后」算，不按「现在」算。因为扩容比换机便宜，但频繁扩容也烦。

第二：类型按「业务」选，不按「价格」选。数据库必须 SSD，归档可以 HDD。

第三：IOPS 要主动问，不能默认。因为它决定「并发时会不会卡」。

三条结论里，第三条最容易被跳过，也最容易造成「明明配置够却卡」的困惑。所以「硬盘选型」这件事，80% 的功夫在「问清 IOPS」，而不是在「比容量」。而这一步只需要一句话，却能避免后面所有的性能困惑。

再看一个「硬盘与整体配置」的匹配。

4 核 8G 的机器配 20G 硬盘，是配置失衡。

因为算力和内存都够，但存不下东西。

所以「硬盘要和配置匹配」。

而<'rabisu'+'> 那种 4 核 8G 配 60G 的档，比例相对合理。

还有一条：「硬盘满」比「CPU 满」更常见。

因为 CPU 会自动排队，而硬盘满了服务直接挂。

所以「磁盘使用率」这个监控项，应该比「CPU 使用率」更受关注。

最后回到开头：四列里只有硬盘的差异能到 500 倍。

而这个悬殊比例说明「硬盘是最能按需买的一项」。但前提是「三个变量都问清」，而这三个变量里有两个问不出答案，只能自己跑测试——只看容量，等于只看了三分之一，而剩下的三分之二才是「卡不卡」的答案。

本文讨论硬盘容量、类型与 IOPS 的一般原理与测量方法，不针对任何具体商家，也不对任何产品作性能评价。文中给出的容量计算、延迟区间、IOPS 需求与「可用率」估算均为按通用经验整理的参考值，不是行业标准；实际性能受接口类型、RAID 配置、共享比例、队列深度与负载特征影响，差异可能很大。各产品的硬盘类型、IOPS 配额、是否按容量比例分配与超额政策均须以商家书面说明与实测结果为准，其中多数商家不公开 IOPS 配额。文中所有数字均为参考值，不构成任何性能承诺或购买建议，亦不代表本站立场，也不代表对任何具体产品的推荐。因按本文估算采购后容量不足或性能不达预期所产生的直接或间接损失，作者及本站不承担任何责任。