我问这个问题的原因是我们有一个专用的 RAID10 阵列，大约 150GB 用于 tempdb(“t”驱动器)。它仅用于存储tempdb。 SQL Server 或任何其他进程不会将 t 驱动器用于其他用途。
我们的 DBA 设置了 tempdb，初始大小为 15GB，增量为 20% 自动增长。每次服务器启动时，它的大小都会调整为 15GB，然后一天中会增长到约 80GB(平均)。现在，IT 部门正在考虑将初始大小增大到 30 或 40GB，但考虑到该驱动器仅用于 tempdb，我的想法是为什么不立即“最大化”。
简单地在 tempdb 的主组中创建 4 个数据文件，每个文件的初始大小为 30GB(总共 120GB)，关闭自动增长并完成它，是否会有任何负面影响？
SQL Server 在一个查询中跨越多个 tempdb 数据文件的能力是否有任何限制？即，如果 tempdb 总共有 70GB 可用空间，但一个进程使用的文件已满(已使用 30GB 中的 30 个)，是否会导致问题？
最佳答案
我会将它们的大小设置为大约 100GB 并保持自动增长，这样您就不必每次都等待它增长，我还会添加多个文件
Is the any negative effect to simply create 4 data files in the primary group for tempdb give them each an initial size of 30GB, turn autogrow off and be done with it?
对我来说听起来是一个不错的计划，但是我会保留自动增长，以防万一有人决定在该列上没有索引的大表上执行排序操作
另请参见此处:http://technet.microsoft.com/en-us/library/cc966534.aspx
- 建议为 0.25 比 1 每个的数据文件(每个文件组) 主机服务器上的 CPU。
- 对于 TEMPDB 来说尤其如此 其中推荐为 1 个数据 每个 CPU 的文件。
- 双核算作 2 个 CPU；逻辑的 procs(超线程)则不然。
关于sql - 仅仅最大化 tempdb 并且从不改变它的大小是否有任何逻辑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5720120/