控制 tempdb 活动如何跨驱动器拆分（固态和旋转驱动器上的 tempdb）

我在一小时内看到以下 tempdb I/O 行为：

机器上执行的多个 DW 工作负载会产生大量磁盘 I/O，其中一些无法容纳分配给 SQL 的约 280GB 内存。一个有趣的方面是，如此多的 I/O 都集中在旋转磁盘驱动器 (E) 上，而不是处理 I/O 效率更高的固态驱动器（F 和 G）上。

我们已将 F 和 G 驱动器上的全部 300GB（总共 600GB）预先分配给 tempdb（使用 12 个文件），并且我们已将 1.3TB 预​​先分配给 E 驱动器上的 tempdb（当前为 1 个文件）。上面的 I/O 数据表明 tempdb 的使用是根据文件的当前大小分布在文件中的。我找不到关于此的文档，但我还运行了如下查询以进一步调查：

-- While running this query, writes to tempdb are distributed to E/F/G drives
-- in proportion to their current size.  This was shown by both
-- sys.dm_io_virtual_file_stats and the space used on the tempdb files before and after
SELECT TOP 100000000 *
INTO #temp
FROM [A_Really_Big_Table]

理想的行为是 F 和 G 被独占使用，除非它们都已满，在这种情况下，旋转磁盘驱动器应提供额外的 tempdb 空间，以便可以在不耗尽 tempdb 空间的情况下处理偶尔非常大的工作负载。

我们是否在正确的轨道上观察到 tempdb 的使用是根据文件的当前大小分布在文件之间的？看到这种类型的分布而不是看到每个文件的平等使用有点令人惊讶（这可能是设置此硬件的人的假设，并决定只将一个文件分配给旋转磁盘上的 tempdb）。

根据 Paul White 对这个问题的回应，我们正在考虑以下方法：

• 收缩旋转磁盘上的 tempdb 文件。根据我们的初步测试，这应该会将当前的工作分配更多地转移到固态驱动器上
• 配置固态 tempdb 文件以预分配它们的空间（正如我们现在所做的那样）
• 将旋转磁盘 tempdb 文件配置为从不分配开始。确保即时文件初始化已打开。Tempdb 将仅在需要时在旋转磁盘上增长（可能最多每周一次）。
• 创建一个维护计划，在高峰负载后缩小旋转磁盘上的 tempdb 文件，使分布重新有利于固态 tempdb 文件。

这看起来合理吗？是否有任何替代方法或潜在问题需要考虑？我们显然会尽可能地测试该方法，但无法在完全等效的测试硬件上进行测试。