本地开发机实战：用 VMware + 直通 NVMe 盘跑数据库，性能损耗到底有多少？

最近接了个离线环境的数据库调优项目，需要在本地搭一套尽量贴近生产的环境。手头的开发机是一台 13 代 i7 + 32G 内存 + 1TB NVMe 的 Windows 机器。生产是物理机直跑 MySQL，本地只能用虚拟机。为了搞清楚虚拟化到底吃掉多少 IO 性能，我做了几组对照测试，结果比预想的有意思。

一、测试环境

宿主机：i7-13700 / 32G DDR5 / 1TB PCIe 4.0 NVMe（系统盘 C:）

虚拟机：VMware Workstation 17 Pro，分配 8 核 16G

对照组：

A：VM 虚拟磁盘放在 C 盘（NVMe 上的 VMDK 文件）

B：VM 第二块盘直接物理直通一块外接 NVMe（通过 SATA/USB 转接或主板第二 M.2）

C：宿主机物理机直接跑（作为基准）

二、测试项与结果

用 fio 测随机读写（4K 随机读、4K 随机写、128K 顺序读），用 sysbench 跑 MySQL 的 OLTP 读。

场景    4K 随机读 IOPS    4K 随机写 IOPS    128K 顺序读    MySQL TPS
C 物理机基准    780K    420K    5.8 GB/s    3800
A 虚拟磁盘在 C 盘    310K    180K    2.1 GB/s    2200
B 物理直通 NVMe    690K    390K    5.2 GB/s    3500
三、数据解读

VMDK 文件虚拟磁盘的损耗非常大，随机写 IOPS 只有物理机的 43%。原因不只是虚拟化层，还有宿主机 NTFS 文件系统 + VMware 的虚拟磁盘格式在写放大上的开销。

物理直通 NVMe 后，损耗大幅收窄，4K 随机读恢复到物理机的 88%，MySQL TPS 恢复到 92%。剩下的损耗主要来自 CPU 虚拟化（VT-x）下的中断处理和上下文切换。

顺序读的损耗比随机小得多，说明瓶颈主要在小块 IO 的路径长度上——虚拟磁盘多了一层文件系统映射，每次 IO 都要经过 guest→VMware→NTFS→NVMe 的多级转发。

四、进一步优化：CPU 与中断

把 VM 的虚拟 CPU 绑核（避免 vCPU 在物理核之间迁移），并开启 VMware 的 vhv.enable = "TRUE"（嵌套虚拟化对 IO 线程调度有帮助），MySQL TPS 又提升了约 8%。另外，把虚拟磁盘的控制器从 LSI Logic 换成 NVMe 控制器（VMware 17 支持虚拟 NVMe），随机读 IOPS 又涨了约 15%。

五、结论

如果只是写代码、跑轻量服务，虚拟磁盘完全够用。但做数据库、存储类开发，虚拟化层的 IO 损耗不可忽视，有条件的话物理直通一块盘，能拿回 90% 左右的性能。另外虚拟 NVMe 控制器 + vCPU 绑核，是性价比最高的两个调优开关。

这套对照数据也提醒我：以后评估“虚拟机性能够不够”，别只看 vCPU 和内存，存储路径的形态往往才是决定性因素。