TG咨询做NVMe本地盘IOPS优化时，很多人先看厂商标称的峰值数字，再直接调整参数，结果业务延迟没有下降，甚至出现写入抖动。IOPS是每秒完成的输入输出操作数，必须结合块大小、读写比例、队列深度和延迟理解。下面六个误区，正是本地盘调优中最容易被忽略的地方。
误区一：接口带宽越高，IOPS一定越高
PCIe 4.0或PCIe 5.0决定的是链路传输能力，不等于所有场景都能获得对应的随机读写性能。以4KiB小块随机访问为例，瓶颈可能出现在固件、闪存介质、主机CPU、文件系统或应用并发，而不是接口本身。
检查时应先确认本地盘实际运行的PCIe代际和通道数量，再观察业务负载。如果应用只发出较低并发的请求，升级更高代际接口通常不如减少锁竞争、优化请求批量有效。接口速率适合解决大文件顺序传输瓶颈，不应被当作提升所有IOPS的通用开关。
误区二：只看厂商最高IOPS，不看测试条件
标称峰值往往建立在特定条件下，例如4KiB访问、较高队列深度、特定读写比例和未满盘状态。真实业务可能是70%读、30%写，也可能主要是同步写入；两者的结果差异很大。
进行NVMe本地盘IOPS优化前，应让测试条件尽量接近业务：
- 记录实际块大小，数据库页、日志写入和对象存储通常并不相同。
- 分别测试随机读、随机写和混合读写，不要只跑单一读测试。
- 至少比较低队列深度与中高队列深度，观察延迟是否随并发快速上升。
- 在盘容量使用率较低和接近业务常态的情况下各测一次。
误区三：队列深度越大，IOPS越高越好
提高队列深度可以让设备保持忙碌，但也会增加排队延迟。很多交互式数据库、虚拟桌面和小型服务更关心低队列深度下的响应时间，而不是队列深度达到32或更高时的峰值。
如果队列深度从1提高到8后IOPS增长有限，延迟却明显上升，说明设备或应用已经接近有效吞吐边界。此时继续加并发只会制造排队。更合理的做法是按业务的并发模型设置线程数，并同时观察平均延迟、P95或P99延迟，而不是只追求一个最大IOPS数字。
误区四：把大块顺序吞吐当成随机IOPS
视频归档、备份和镜像复制偏向大块顺序访问，4KiB随机访问则常见于索引、元数据和小文件场景。前者更关注MB/s，后者更关注IOPS与延迟。一个顺序写入很快的盘，不代表它在低队列深度随机写中同样出色。
优化前先画出业务访问画像：小块还是大块，顺序还是随机，读多还是写多。若应用主要传输256KiB以上的大文件，盲目调整随机IOPS没有意义；若应用频繁访问4KiB至16KiB数据，则应优先关注低延迟随机读写能力。
误区五：关闭缓存或强制同步写，性能一定更差
写缓存、操作系统缓存和应用缓存会改变测试结果，但不能简单用“开启”或“关闭”判断优劣。数据库使用同步提交时，需要确认数据真正落盘；如果为了追求高IOPS而绕过持久化保证，断电或设备故障可能造成事务丢失。
执行NVMe本地盘IOPS优化时，先明确数据安全要求，再分别测试同步写和异步写。PostgreSQL这类数据库的提交策略、日志刷盘频率和检查点行为，都会影响盘的写入压力。缓存适合吸收突发请求，但不能替代可靠的持久化机制。
误区六：只调本地盘，不检查应用和文件系统
当多个进程争用同一块盘时，CPU调度、内存不足、文件系统日志、后台扫描和写放大都可能成为瓶颈。即使盘本身还有余量，应用锁、线程池过小或请求没有批量化，也会让IOPS上不去。
一套较稳妥的排查顺序
- 先记录业务的读写比例、块大小、并发数和可接受延迟。
- 确认盘的容量占用、健康状态、固件版本和实际链路状态。
- 用接近真实负载的测试比较低、中、高队列深度。
- 分别观察设备利用率、CPU占用、内存回收、文件系统等待和应用队列。
- 一次只改一个变量，回归测试后再决定是否保留。
盘接近满载时，后台整理和写放大通常会使写入延迟波动；高并发服务还可能需要分散日志与数据访问，或通过多块盘降低单设备竞争。这里的目标不是制造最高峰值，而是在可接受延迟内获得稳定的有效IOPS。
常见问题
1. IOPS越高，业务一定越快吗？
不一定。若应用受CPU、锁、网络或同步提交限制，盘的峰值IOPS无法直接转化为业务性能。
2. 低队列深度为什么很重要？
许多在线请求不会同时堆积大量I/O，低队列深度更接近交互式服务的实际响应路径。
3. 是否应该把盘分成多个分区来提升IOPS？
分区本身通常不会增加物理闪存性能。只有在分离日志、临时文件和数据、减少访问竞争时，才可能改善整体表现。
4. 如何判断优化是否有效？
使用同一数据集和相近负载，对比IOPS、平均延迟及P95或P99延迟，并确认错误率和数据安全策略没有恶化。
归根结底，NVMe本地盘IOPS优化应从真实工作负载出发，把接口、队列、缓存、文件系统和应用并发放在同一条链路上分析，才能获得稳定而不是短暂的性能提升。
