为何SQL Server在两台虚拟机还原时未充分利用磁盘最大IO性能？

这个问题我之前帮客户排查过类似的场景，带大体积FileStream的SQL Server备份还原确实容易出现这种“磁盘性能过剩但用不上”的情况，结合你的环境细节和等待类型，主要原因可以从这几个方面拆解：

1. 单FileStream容器的并行度瓶颈 #

你当前只配置了1个FileStream文件组/容器，而SQL Server在处理FileStream备份还原时，单个容器的Blob数据处理默认是单线程串行执行的。哪怕你的磁盘能跑300MB/s，但面对11.8万个平均200KB的小Blob文件，单线程逐个读取/写入这些小文件的效率极低——磁盘的高带宽优势需要连续大IO才能体现，小文件的频繁随机IO（哪怕是顺序遍历）会让磁盘队列一直处于“零碎任务”状态，根本跑不满标称带宽。

2. 默认备份还原参数不匹配FileStream场景 #

SQL Server默认的备份参数（MAXTRANSFERSIZE=65536即64KB，BUFFERCOUNT由系统自动分配）是针对普通数据文件优化的，并不适合大量小Blob的FileStream场景：

• 64KB的传输大小远小于你的平均Blob大小（200KB），导致每个Blob需要多次IO操作才能完成读写，线程频繁切换等待IO，反而降低了整体吞吐量；
• 自动分配的缓冲区数量可能不足，导致备份线程经常处于等待缓冲区释放的状态，进一步限制了IO利用率。

3. FileStream还原的文件系统元操作开销 #

虽然你开启了IFI（即时文件初始化），但IFI仅对SQL Server的数据文件和日志文件生效，FileStream容器内的小Blob文件无法享受IFI加速。还原时需要逐个创建这11.8万个小文件，文件系统的元数据操作（比如目录项更新、文件分配表修改）是串行化的高开销操作——哪怕磁盘IO再快，文件系统的元处理能力跟不上，也会拖慢整体还原速度，表现为BACKUPIO等待持续居高。

具体解决建议 #

针对你的环境，建议按以下步骤优化：

（1）拆分FileStream容器 #

将单个FileStream容器拆分为多个（建议数量等于CPU逻辑核心数，比如8核就建8个），这样SQL Server备份还原时可以并行处理不同容器内的Blob数据，充分利用磁盘的并行IO能力。操作步骤：

-- 添加新的FileStream容器
ALTER DATABASE YourDB
ADD FILE (NAME = N'FSContainer2', FILENAME = N'D:\FSData\FSContainer2')
TO FILEGROUP [FileStreamFG];
-- 重复添加至目标数量

之后可以通过移动Blob数据到新容器（或重建索引）来分散数据。

（2）调整备份还原参数 #

使用更大的传输单元和合适的缓冲区数量，提升单次IO的有效数据量：

• 备份命令示例：

BACKUP DATABASE YourDB
TO DISK = N'C:\Backup\YourDB_Full.bak'
WITH COMPRESSION, 
     MAXTRANSFERSIZE = 4194304, -- 4MB，匹配你的平均Blob大小
     BUFFERCOUNT = 64, -- 根据服务器内存调整，建议每GB内存分配8-16个缓冲区
     STATS = 5;

• 还原命令示例：

RESTORE DATABASE YourDB
FROM DISK = N'C:\Backup\YourDB_Full.bak'
WITH REPLACE,
     MAXTRANSFERSIZE = 4194304,
     BUFFERCOUNT = 64,
     STATS = 5;

（3）优化文件系统配置 #

• 将FileStream存储磁盘的NTFS簇大小调整为64KB（默认4KB），减少小Blob文件的磁盘碎片和元数据开销；
• 禁用磁盘的8.3文件名格式（执行fsutil behavior set disable8dot3 1），进一步降低文件系统元操作的开销；
• 确保磁盘采用RAID 10（而非RAID 5）配置，提升随机IO和小文件处理的性能。

（4）验证并行度与等待类型 #

优化后可以通过以下方式验证效果：

• 用性能监视器观察磁盘的% Disk Time和Disk Bytes/sec指标，确认磁盘带宽是否被充分利用；
• 用sys.dm_os_wait_stats或SSMS的活动监视器查看等待类型，BACKUPIO和BACKUPITHREAD的等待时间应大幅降低。

内容的提问来源于stack exchange，提问作者Ace