我试图找出是否有可能在不重新启动SQL Server服务的情况下将tempdb文件添加到SQL Server。我在数据库管理员那里看到了这个答案：
一个答案指出：
添加-无需中断。尽管正如Microsoft的Sean指出的那样，SQL将更喜欢使用填充较低的文件。如果您要从1个数据文件开始添加更多数据，则SQL会在一段时间内使用新数据文件，但是您的性能不会比仅拥有一个文件更糟。但是，如果您已经有2个以上并添加一个以上，则它将在新的1个热点上出现并降低性能。
但是，有一条评论警告以下内容：
我将在“添加”部分添加一个附录：“添加：不，但是您很可能会失衡，所以您会发现热点，这会使情况变得更糟。”
我有关于该评论的以下问题，但被指示在我自己的新问题（此问题）中提出这些问题，而不是通过对该问题的答案中的评论来询问评论者。
特别：
Answers:
什么是热点？
在这种情况下，“热点”意味着，即使tempdb有多个文件，所有I / O工作仍在单个文件中完成。如果tempdb忙于证明添加文件的合理性，则导致热点现象的不平衡（由于比例填充）将是短暂的，因此我认为警告可能有点鸡小。无论如何，以我的经验。
热点问题会使tempdb变得更糟吗？
我认为这在tempdb中被认为更糟，因为它在大多数工作负载中首当其冲地进行了写活动。您肯定会在用户数据库中遇到类似的问题，但是由于您已经在尝试解决tempdb中的问题...
数据库中哪些特定的事情会变得更糟？
主要是写时间。想象一下每个人都在尝试使用同一台ATM，即使附近还有其他7台ATM。在任何时间点只能写入太多内容；其他一切都必须等待。使用更多文件（以及足够的内核来安排工作），I / O可以更均匀地分布。
只要确保：
- 什么是热点？
Aaron是正确的，我不会重复他上面所说的内容，但这不仅仅涉及磁盘IO。大多数人在TempDB中遇到的主要问题是由于对某些跟踪结构的争执。
由于具有多个tempdb文件，使得按比例填充和循环算法可以有效地实现分配之间的“公平”，因此添加没有分配的新文件会有些许困难。我确实不同意，如果您开始看到PAGELATCH_*等待的是所述新文件，而其他文件上没有太多或任何其他内容，则这是“小鸡鸡”警告（请参阅下面的产品更新）。这通常发生在具有较高TempDB活动并且已经具有多个文件的系统上。
请注意，SQL Server 2019中有一些选项可以将某些基础系统表更改为内存中表，这可以有所改进，因为内存中对象的分配方式与磁盘烘焙表的分配方式不同。基于磁盘的表是多年来我们一直在使用的传统表。SQL Server 2014引入了内存优化表。SQL Server 2019可以处理内存优化表中的某些分配元数据。
SQL Server 2019中进行了另一项更改以帮助并发PFS更改，这通常是分配中内存结构的争用正在PAGELATCH_*等待的内容。
- 热点问题会使tempdb变得更糟吗？
没什么恕我直言。是的，TempDB有更多的项目可以导致对其进行写入而无需直接使用，因此它可能会妨碍某些项目。但是，就数据更改率而言，非常繁忙的用户数据库也同样糟糕。它不仅限于TempDB。
- 数据库中哪些特定的事情会变得更糟？
我真的很喜欢亚伦的比喻！这就是正在发生的事情的本质。真正恶化的是数据库中对象的空间分配和跟踪。如果您的用户数据库大多是静态的（变化率低），或者您的TempDB并未真正使用，那么您将不会有任何注意。但是，如果这是一个非常繁忙的服务器，则您可能会启动或加剧分页等待，这可能会导致车队阻塞。
Aaron已经指出，在较旧的版本上，有跟踪标志可确保使用统一的扩展区，并确保文件组中的所有文件一起增长（Aaron指出1117和1118是2016+年的NOP）。我想再次指出的另一件事是，这不仅适用于TempDB，而且适用于任何数据库，应根据需要考虑物理布局。
这不仅是针对热点问题，还适用于系统的其他部分，例如备份/还原，文件管理，文件系统元数据碎片等，这些都可以通过拥有多个文件来解决。
您可以通过waitresource在PFS页面（第1页，然后每8088页）上查找来查看分配结构竞争。如果看到所有文件都在同一个文件（2：file：page）中，那么您就知道发生了这种情况。