Sql 只是最大化tempdb，而从不改变它的大小，这有什么逻辑吗？

我问它的原因是我们有一个专用的RAID10阵列，用于tempdb（t驱动器），容量约为150GB。它仅用于存储tempdb。SQL Server或任何其他进程都不使用t驱动器来执行任何其他操作

我们的DBA具有tempdb设置，初始大小为15GB，自动增长20%。每次服务器启动时，它的大小都会调整到15GB，然后在一天的过程中会增长到约80GB（平均）。现在，它正在考虑将初始大小变大，比如30或40GB，但鉴于该驱动器仅用于tempdb，我的想法是为什么不立即“最大化”

简单地在tempdb的主组中创建4个数据文件是否会产生任何负面影响？为每个文件指定30GB（总共120GB）的初始大小，关闭“自动增长”并使用它

---

SQL Server在一个查询中跨越多个tempdb数据文件的能力是否有任何限制？i、 e.如果tempdb的总可用空间为70GB，但一个进程使用的文件已满（使用了30GB中的30个），是否会导致问题？

我会将其大小调整到100GB左右，并保持自动增长，这样您就不必等待它每次增长，我还会添加多个文件

这对我们来说有什么负面影响吗 在主数据库中创建4个数据文件 tempdb组给他们每人一个 初始大小为30GB，启用自动增长 走开，把它干掉

对我来说，这听起来是个不错的计划，但我会让autogrow保持开启状态，以防有人决定对一个大表执行排序操作，而该表的列上没有索引

另见此处：

• 建议使用0.25到1 每个文件组的数据文件（每个文件组） 主机服务器上的CPU
• 对于TEMPDB来说尤其如此 其中建议为1个数据 每个CPU的文件数
• 双核计数为2个CPU；符合逻辑的 程序（超线程）不允许

---

我们发现创建大型TempDB数据和日志文件非常有用。任何限制服务器操作系统活动的操作（如调整TempDB大小）都会提高服务器效率。我们有一台16处理器、113 GB的机器，专门用于TempDB数据空间。此机器专用于大型SSIS ETL进程，因此会导致大量数据操作

我们的大部分ETL操作产生多达4个SQL线程。在最初为每个处理器（16）配置TempDB文件之后，我们通过性能监视很快意识到，我们的配置迫使SQL\windows不必要地跨越多个TempDB文件。我们选择了5个更大的TempDB数据文件，并实现了性能改进。此后，我们采用了24处理器的机箱，并使用了8个TempDB文件

---

请注意，这是一个大型数据迁移服务器；我相信面向事务的系统仍然会受益于推荐的1-1处理器到TempDB文件配置。还应注意的是，TempDB文件的大幅增加%可能会迫使关键事务受到windows操作的影响，因此可能不适合您的特定应用程序。

在

TempDB

上关闭

autogrow

，这是一个非常糟糕的主意，因为如果它达到限制，您的查询就会消失……I我想我的想法是，自动增长与否的限制是磁盘大小在137GB左右。所以120GB的固定tempdb或者120GB的tempdb可以自动增长到137GB看起来并没有太大的区别。但是，他对自动增长没有问题吗？如果你预先确定了它的大小，那就没什么大不了的了，但是如果tempdb需要增长，它可能会引起问题。我发现我在我的回答中遗漏了报价下面的自动增长部分，我会更改它。系统有16个内核，所以我们使用了8个数据文件。要扩展这一点，使用8x 12GB数据文件并启用自动增长（驱动器最大输出为137GB）或仅使用8x 17GB数据文件而不使用自动增长是否有任何优势。将tempdb最大化到驱动器上的所有可用空间（或者可能是95%+）而不是一个更小的tempdb（最终会增长到这个大小）有什么缺点吗？我会尽可能地调整它的大小，这样它就永远不需要增长，反正你也不会使用t驱动器做任何其他事情