物理机数据库随机读写：机械盘、SATA SSD与NVMe的IOPS差多少？

在相同服务器平台、相同块大小和相同随机读写模式下，机械盘通常只有几十到几百 IOPS，SATA SSD通常进入数万 IOPS，NVMe SSD则常见于数十万甚至更高的量级。换算成数据库更关心的差距，SATA SSD相对机械盘往往是数百倍提升，NVMe相对机械盘可能达到千倍以上；但SATA SSD与NVMe之间并不是固定的十倍差距，低队列深度、同步写入和具体闪存颗粒会让结果明显变化。

对数据库而言，不能只看厂商标注的最高 IOPS。机械盘的随机寻道延迟、SATA SSD的接口与协议限制、NVMe的并行队列能力，最终都会反映到索引查询、事务提交、WAL或Redo日志、检查点以及高并发请求的尾延迟上。真正需要比较的是：在接近实际数据库的块大小、队列深度、读写比例和持久化要求下，哪种磁盘能够稳定地完成业务所需的 I/O。

共同前提：先把比较口径锁定

三类磁盘比较的对象是什么

这里的机械盘，指用于物理机本地存储的传统硬盘，重点关注随机访问能力，而不是连续读写带宽。SATA SSD指通过SATA接口连接的固态硬盘，NVMe则指通过PCIe总线、使用NVMe协议的固态硬盘。

这三者可以作为数据库存储介质进行横向比较，但不能把不同产品等级简单归类。例如：

• 一块带掉电保护、较高写入耐久度的企业级SATA SSD，与消费级QLC SATA SSD并不等价。
• 一块安装在PCIe扩展卡上的企业级NVMe，与通过M.2接口连接且容易过热的消费级NVMe也不等价。
• 机械盘组成带控制器缓存的RAID阵列后，测试结果不能直接与单块SSD比较。
• 带电池保护写缓存的RAID控制器，可能显著改变同步写入表现，但这并不等于后端磁盘本身拥有同样的持久化能力。

因此，比较时至少要固定以下条件：

1. 单盘还是RAID阵列。
2. 块大小是4 KiB、8 KiB还是16 KiB。
3. 随机读、随机写还是混合读写。
4. 队列深度是1、8、32还是更高。
5. 是否使用直接I/O，是否调用fsync或fdatasync。
6. 测试的是平均延迟、P95/P99延迟，还是单纯的峰值IOPS。
7. SSD处于空盘、半满还是接近满盘状态，是否经过长时间持续写入。

IOPS不是一个固定不变的产品参数

IOPS表示每秒完成的I/O操作次数。它与吞吐量的关系可以简单表示为：

吞吐量 = IOPS × 单次I/O块大小

例如，按8 KiB等于8192字节计算，100,000 IOPS对应：

• 100,000 × 8192 = 819,200,000字节/秒；
• 按十进制换算约为819.2 MB/s；
• 按二进制换算约为781.25 MiB/s。

如果同样是100,000 IOPS，但块大小只有4 KiB，吞吐量就约为409.6 MB/s。反过来，较大的块大小可以提高吞吐量，但不一定适合随机小块数据库访问，也可能增加缓存和写放大压力。

数据库工作负载通常比厂商的顺序读写规格复杂。以常见数据库为例：

• PostgreSQL常见页面大小为8 KiB。
• InnoDB常见页面大小为16 KiB。
• 日志、索引更新和数据页刷新可能使用不同的I/O行为。
• 一次事务提交可能涉及日志写入、刷盘和后续数据页落盘。
• 多个事务可能通过组提交合并为一次实际写入。

因此，4 KiB随机读测试适合观察底层介质的基础能力，但不能直接等同于数据库TPS；8 KiB或16 KiB混合读写、同步写和真实数据库回放更接近生产结果。

典型参考量级

下面的数字用于建立量级概念，属于单盘、未叠加复杂阵列缓存的常见参考范围，不是任何具体型号的实测值或验收承诺。实际结果会受到固件、闪存类型、磁盘容量、温度、文件系统、控制器和队列深度影响。

从这个量级可以看到：

• 机械盘到SATA SSD，随机IOPS可能提升数百倍。
• 机械盘到NVMe，随机IOPS可能提升到千倍以上。
• SATA SSD到NVMe，在低队列深度下常见是数倍差距，在高并发、混合写入或低尾延迟场景中差距可能继续扩大。
• 如果业务主要是连续读写大文件，SATA SSD与NVMe的差距可能小于随机数据库访问中的差距。

核心差异：为什么数据库更容易感知磁盘类别

机械盘的瓶颈是寻道和旋转等待

机械盘执行随机I/O时，磁头需要移动到目标磁道，并等待盘片旋转到对应位置。即使每次只读取几KiB，也可能承担毫秒级的定位成本。

数据库的索引访问往往是离散的。一次查询可能先读取索引页，再读取数据页；多个并发请求又会访问不同的数据块。连续读写可以让机械盘利用预读和顺序访问优势，但随机访问很难维持高效率。

机械盘的典型表现是：

• 队列深度增加后，IOPS不会线性增长。
• 并发请求越多，等待队列越长。
• 平均延迟可能尚可，但P99延迟容易明显升高。
• 小事务频繁提交时，日志刷盘会反复触发随机写。
• 数据库检查点、索引维护和备份任务容易与在线请求互相影响。

机械盘并非完全不适合数据库。对冷数据、低并发业务、日志归档和备份仓库来说，它仍然具备容量成本优势。但如果主库需要持续处理大量随机事务，机械盘通常会先成为瓶颈。

SATA SSD解决了寻道问题，但仍受接口和协议限制

SATA SSD没有机械寻道和旋转等待，随机访问延迟从毫秒级降到亚毫秒级，因而即使在队列深度为1时，也能明显改善数据库响应。

不过，SATA接口本身的链路能力有限。SATA 6 Gb/s的理论链路速率约为600 MB/s，扣除编码和协议开销后，实际可用带宽通常更低。对4 KiB或8 KiB随机I/O而言，SATA SSD仍然可以提供很高的IOPS，但在高并发或大块混合读写下，接口可能成为上限。

SATA SSD的特点可以概括为：

• 相比机械盘，随机读写和尾延迟改善明显。
• 低队列深度下已经足以满足不少中小型OLTP业务。
• 多块SSD共享同一SATA控制器或背板时，可能出现链路竞争。
• 不同主控、闪存类型和缓存设计会造成较大的写入差异。
• 消费级SSD在持续写入、接近满盘或缓存耗尽后，性能可能回落。

所以，不能只看到“SATA SSD”这个名称就认为所有产品表现相同。数据库主盘、日志盘和高频写入场景，通常更需要关注掉电保护、持续写入能力和耐久度，而不是只比较空盘状态下的峰值IOPS。

NVMe的优势不仅是带宽更高

NVMe通过PCIe连接存储设备，并针对闪存设计了更高并行度的队列模型。与SATA相比，它减少了传统协议栈中的部分限制，也能更充分地利用多通道闪存。

对数据库而言，NVMe的价值主要体现在三个方面：

1. 低队列深度下的响应时间更低

数据库中的部分关键路径并不会产生很深的I/O队列，例如单线程事务提交、日志刷盘和随机索引访问。此时，低延迟比峰值IOPS更重要。

1. 高并发下的并行能力更强

当多个数据库工作线程同时读写时，NVMe可以承载更多并发请求，减少设备队列排队。

1. 大块混合读写的吞吐空间更大

检查点、批量更新、索引构建和分析查询可能同时产生较大的读写流量。NVMe在PCIe链路和设备队列方面更有余量。

但NVMe并不意味着数据库性能一定按比例提升。如果应用受制于锁竞争、CPU计算、内存不足、网络延迟或SQL执行计划，换成更快的磁盘后，整体吞吐可能只提升有限。

同步写入时，平均IOPS不如延迟和持久化能力重要

数据库事务提交通常需要确认日志已经写入稳定存储，具体过程可能涉及fsync、fdatasync或等价的持久化操作。此时，操作系统页缓存和SSD内部易失缓存不能简单视为已经安全落盘。

需要区分以下几种结果：

• 异步随机写IOPS：设备可以积累较多请求后并行处理，通常数值较高。
• 同步随机写IOPS：每次写入都需要等待持久化确认，更接近事务提交路径。
• 带掉电保护的写缓存：在满足硬件保护条件时，控制器或SSD可以较快确认写入。
• 无掉电保护的缓存：即使测试结果很高，断电时仍可能丢失已经被系统认为完成的数据。

机械盘在同步随机写场景下通常最吃亏。SATA SSD可以显著降低单次等待，但如果没有掉电保护，不能只凭性能数字作数据库主盘选择。NVMe企业盘通常在并行度、延迟和持久化设计上更有优势，但也必须核对具体型号和服务器兼容性。

业务影响：IOPS差距如何传导到数据库

OLTP查询首先感知随机读延迟

在线交易系统常见的单条查询不一定需要大量数据，但会频繁访问索引页、数据页和锁相关结构。当热点数据无法完全放入内存时，磁盘随机读就会进入请求路径。

同一条SQL在三类磁盘上的差异可能表现为：

• 机械盘：单次I/O等待占比高，并发增加后排队明显。
• SATA SSD：大多数随机读可在亚毫秒级完成，适合中等并发的业务。
• NVMe：在高并发或对P99延迟敏感的业务中，通常有更大的延迟余量。

如果数据库缓冲池足够大，热点数据全部命中内存，读盘差距可能不会立即体现。但这并不表示磁盘不重要，写入、检查点、缓存淘汰和冷数据访问仍然会触发后端I/O。

事务提交更容易放大随机写差距

可以用一个简化模型估算数据库对持久化I/O的需求：

有效持久化IOPS ≈ 每秒事务数 × 每个事务产生的持久化I/O次数

例如，一个业务每秒提交2000个事务，每个事务至少触发一次日志持久化，那么日志路径至少需要处理约2000次同步写请求。若事务还会导致数据页和索引页刷新，实际后端I/O可能更高。

这个计算不能直接等同于磁盘必须提供2000个物理IOPS，因为数据库可能使用：

• 组提交，将多个事务合并到一次日志刷盘。
• 日志顺序写，减少数据页的即时随机写压力。
• 缓冲池延迟刷新数据页。
• 批量更新和后台写回，改变物理I/O时序。

但它能说明一个现实问题：即使业务吞吐只有几千TPS，日志和数据页的持久化路径也可能很快超过机械盘的随机处理能力。

检查点和后台任务会制造第二种压力

数据库并非只有前台查询。检查点、自动清理、索引构建、统计信息更新、备份和复制都会消耗磁盘资源。

机械盘在在线事务与后台任务并发时，常见现象是：

• 前台查询延迟突然升高。
• I/O等待时间增加，CPU使用率反而不高。
• 数据库连接数增加，但TPS没有同步增长。
• 检查点耗时变长，日志积压或复制延迟扩大。
• 备份任务运行期间，在线业务出现长尾延迟。

SATA SSD可以降低这类互相抢占，NVMe则适合需要同时处理在线事务、日志和较大后台任务的物理机。但如果所有任务仍然共用一个容量不足或散热不良的设备，NVMe的优势也可能被持续写入降速抵消。

IOPS高不等于TPS一定高

数据库TPS还受到以下因素影响：

• SQL执行计划和索引设计。
• 锁等待与事务冲突。
• CPU单核性能和上下文切换。
• 内存容量及缓冲池命中率。
• 数据库连接池和线程模型。
• 网络来回时延。
• 日志同步策略和复制确认策略。

因此，不能用“NVMe有几十万IOPS，所以TPS会提升几百倍”的方式做容量规划。更合理的判断是：磁盘升级后，I/O等待是否下降，P95/P99事务延迟是否改善，数据库是否能够维持更稳定的并发度。

成本与限制：性能之外还要看什么

容量成本和性能成本不是一回事

机械盘通常适合以较低单位容量成本保存大量数据，适用于：

• 备份文件和归档数据。
• 访问频率较低的历史库。
• 报表库中的冷数据。
• 对延迟要求不高的文件型业务。

SATA SSD通常是容量、性能和兼容性之间较平衡的方案。已有大量SATA盘位、业务并发中等、预算需要控制时，它往往比直接上NVMe更容易落地。

NVMe更适合把预算投入到低延迟和高并发能力的场景，例如：

• 核心交易主库。
• 高频日志写入。
• 大量随机更新的订单、库存或计费系统。
• 对P99延迟有明确要求的在线服务。
• 需要在同一主机上并行运行数据库和高强度后台任务的环境。

成本比较不能只看采购单价，还应加入盘位、扩展卡、背板、RAID控制器、散热、备件和替换周期等因素。

掉电保护和写入耐久度直接关系到数据库安全

数据库主盘和日志盘需要重点核对：

• 是否具备硬件掉电保护。
• 标称写入耐久度是TBW还是DWPD。
• 持续写入后是否明显降速。
• 盘满比例达到多少后性能会变化。
• 是否支持服务器现有的监控和告警体系。
• 固件升级、盘片更换和阵列重建是否有明确流程。

消费级SSD可能在短时间测试中表现很好，但长时间写入、满盘运行或断电场景下的表现未必适合关键数据库。尤其是写密集型日志、临时表、排序空间和高频更新表，不应只根据顺序读写带宽选盘。

RAID和控制器会改变最终结果

单盘对比只能说明介质差异，生产环境还要考虑阵列布局。

• RAID 1或RAID 10通常更容易获得可预测的随机读写和故障恢复能力，但可用容量会减少。
• 带校验的阵列在小块随机写入时可能产生额外读改写开销。
• 控制器写缓存可能短时间提高同步写结果，但必须确认电池或闪存保护是否正常。
• 多块NVMe组成阵列后，需要确认主板PCIe通道、软件栈和阵列方案是否支持预期性能。
• 阵列重建期间，业务可用IOPS可能下降，机械盘阵列的重建窗口通常更长。

因此，不能用“单块NVMe对比单块机械盘”的结果，直接承诺“机械盘RAID阵列换成NVMe单盘后一定获得相同比例提升”。生产验收应以实际阵列、文件系统和数据库配置为准。

温度、盘位和PCIe通道也可能成为瓶颈

NVMe的性能密度较高，但持续写入时发热明显。服务器前后风道、散热片、盘位位置和固件温控都会影响稳定性能。部分设备在短时间内达到很高IOPS，持续运行后可能出现降速。

同时还要检查：

• NVMe盘是否与其他设备共享PCIe通道。
• 插槽是PCIe 3.0、PCIe 4.0还是其他规格。
• 主板是否支持对应的U.2、U.3、M.2或扩展卡形态。
• 启动盘、数据盘和日志盘是否共用背板或转接设备。
• 操作系统和数据库驱动是否能正常识别设备健康状态。

如果服务器只有有限的PCIe通道，或者NVMe安装在受限的转接路径上，理论上的设备能力可能无法在业务中体现。

验证与验收：不要只复制厂商峰值

先测单盘，再测真实阵列

测试应使用专用测试文件或隔离测试盘，不能直接把写入型测试指向生产数据库文件、裸盘或正在使用的文件系统。测试文件所在目录需要有足够可用空间；如果路径中已有重要数据，应先完成备份并确认影响范围。

Linux环境下可以用fio构造接近数据库的随机读写场景。下面示例以专用测试路径和20 GiB测试范围为例，路径需要替换成实际的隔离挂载点：

fio --name=randrw_qd1 \
  --filename=/srv/bench/fio.test \
  --size=20G \
  --rw=randrw \
  --rwmixread=70 \
  --bs=8k \
  --ioengine=libaio \
  --iodepth=1 \
  --numjobs=1 \
  --direct=1 \
  --runtime=60 \
  --time_based \
  --group_reporting

测试前应确认：

• /srv/bench/fio.test位于专用测试文件系统，而不是数据库数据目录。
• 测试文件可以被覆盖，已有内容已经备份或不再需要。
• 测试机器有足够空间，且不会影响在线业务。
• 系统安装的fio支持所选I/O引擎；如果不支持，应先通过fio --enghelp核对可用引擎，不要直接猜测参数。
• 要比较队列深度影响，可以将--iodepth=1改为--iodepth=32，但应保持其他参数不变。

该命令使用8 KiB、70%读和30%写的混合随机负载，适合作为数据库类负载的起点。它不等于完整的事务提交测试，因为默认并未模拟每次写入都必须持久化确认的场景。需要验证日志刷盘能力时，应在隔离环境中增加同步持久化测试，并核对测试结果是否确实等待设备确认。

重点记录四类结果

单次测试不应只记录IOPS，还应同时记录：

对于数据库，建议再结合应用压测或历史请求回放，观察：

• 事务提交延迟。
• 数据库I/O等待时间。
• 日志写入等待。
• 缓冲池命中率。
• 检查点耗时。
• 复制延迟。
• 高并发下的锁等待和连接排队。

如果fio显示NVMe比SATA SSD快很多，但数据库事务延迟几乎没有变化，应继续检查CPU、锁、内存和SQL执行计划，而不是继续单纯升级磁盘。

决策规则：按业务条件选择介质

适合优先考虑机械盘的情况

机械盘可以用于：

• 数据访问频率较低的归档库和历史库。
• 备份仓库、快照暂存和大容量文件存储。
• 并发较低、事务提交不频繁的非核心业务。
• 预算重点在容量而不是低延迟的场景。

如果机械盘承载的是在线数据库，建议通过内存缓存、冷热数据分层和读写分离降低随机I/O压力，并为后台备份、检查点和在线事务预留资源空间。不要用连续读写速度掩盖随机访问能力不足的问题。

适合选择SATA SSD的情况

SATA SSD通常适合：

• 中小型OLTP数据库。
• 并发量中等、但需要明显降低随机访问延迟的业务。
• 服务器已有充足SATA盘位和成熟阵列方案。
• 预算有限，但又无法接受机械盘的毫秒级随机I/O等待。
• 数据库读多写少，或日志写入压力尚未达到接口上限。

选择时应优先考虑企业级型号、掉电保护、持续写入能力和保修替换流程。对于日志盘和频繁更新的数据盘，不宜只按照容量和峰值读取IOPS选购。

适合选择NVMe的情况

NVMe更适合：

• 高并发在线交易主库。
• 日志、Redo或WAL写入压力较高的数据库。
• 对P95/P99事务延迟敏感的业务。
• 需要同时承担随机读、随机写和后台批处理的物理机。
• 数据库缓冲池无法覆盖主要工作集，且磁盘I/O已经成为明确瓶颈的环境。

此时应确认服务器PCIe通道、盘位形式、散热和监控能力，并优先核对掉电保护和耐久度。若业务写入量很大，可以考虑将日志与数据分离到不同设备或不同阵列，但分离前仍要通过实际压测确认是否减少了资源争用。

适合采用混合存储的情况

很多物理机不必在三类磁盘中全盘选择一种。更实用的组合可能是：

• NVMe承载在线数据库、日志或高频更新表。
• SATA SSD承载普通业务库、索引或读多写少的数据。
• 机械盘承载备份、归档和低频历史数据。
• 通过副本或数据分层，把冷数据逐步迁移到大容量机械盘。

最终选择可以遵循一条简单规则：如果瓶颈是随机I/O等待，先比较P99延迟和同步写能力；如果瓶颈是容量和连续吞吐，机械盘或SATA SSD可能更经济；如果业务在高并发下同时受到日志、数据页和后台任务影响，NVMe更有可能提供足够的并行余量。

对低并发、低频访问的数据库，机械盘的容量优势仍然有价值；对大多数需要稳定随机访问的中型业务，企业级SATA SSD通常是较平衡的起点；对高并发、写入密集或低尾延迟要求明确的核心数据库，则应优先评估带掉电保护和足够耐久度的企业级NVMe，并以真实数据库工作负载完成最终验收。