误区12在#文件数：TempDB和需要的CPU数量一致

错误

既然上述误解是微软的官方建议，而大量博客文章坚持这种观点，误解一直是一个不停的谈话。

但令人困惑的是，SQL猫团队的建议是1:1，但该建议来自于扩展原则，而不是一般规则，因为他们所面对的大客户数据服务器和IO子系统，大多数人没有机会见面。

每个实例只能有一个情况，但也有许多地方需要使用TempDB TempDB，所以很容易成为性能瓶颈，一些人我希望你理解这一点，但大多数人不知道应该在什么情况下增加tempdb文件。

当你看到的pagelatch型阻塞，它显示了一个争论的问题是内存分配位图遇到。见PAGEIOLATCH，说明竞争问题在我/ O子系统级，闩锁（锁）你可以看到它作为一个普通的锁，但是它的重量更轻，短，和只会在存储引擎使用。

MVP Glenn Berry有一个博客，有一个sys.dm_os_wait_stats.in DMV查看这个博客，你可以找出你的服务器造成的最大障碍。如果你发现pagelatch型等，你可以使用这个脚本来看到问题的FPS，GAM引起，或SGAM争夺。

如果你遇到闩锁争用，可以记录1118个或更多的建立tempdb文件缓和局势（以KB 328551知识库的原理来检查），我写了一篇关于为什么标签还需要1118个环节：误解Naga Hirofumi，TF 1118。

在SQL Server 2000次，保持tempdb文件和CPU核心数1:1的关系，也适用于SQL Server 2005和2008版本的这个提议，但因为SQL Server优化措施后2005 +（见我的Bo Wen），你不再需要设置CPU数量，按照1:1的比例核tempdb文件数量严格的关系，但文件数量和CPU核数比保持在1:2和1:4就行。

在SQL传递2011 {主题：我的好朋友Bob Ward，SQL CSS是最牛的人。给出了一个新的公式：如果CPU核心数量小于或等于8，比例保持在1:1，如果CPU核心数量大于8, 8个文件被使用。当发现锁存争用现象时，在另一时间添加4个文件。

但不能一概而论，上个星期我遇到了一个问题。一个客户的tempdb负荷足够大，需要32个CPU和64 tempdb文件缓解闩锁争用。这是否意味着这是一个最佳实践当然不是.

然后你可能会疑惑为什么1:1比例不是很好，因为太多会导致另一个tempdb性能问题。如果您的查询中的一些操作，如排序，需要使用大量的内存，但是如果你没有足够的内存，你需要把这些内容对tempdb。当多个tempdb文件存在，因为tempdb的循环分配机制，这可能导致性能被拖，因为是这样一个大的临时表。

那么为什么循环分配机制所产生的性能问题时，有大量的文件在TempDB吗有以下几种可能性：

循环分配算法是针对文件组，并且只有一个文件组为tempdb。当文件组包含16个或32个文件，由于回路分配有限的线程，因为大量的文件tempdb还需要做一些额外的同步工作，因此这部分的工作会导致性能损失。
对tempdb文件大小不一致，这可能导致一个文件自动增长，导致在一个炎热的IO。
当缓冲区需要通过LazyWriter释放一些空间（tempdb检查站不回写操作），多tempdb文件可能导致随机读写IO子系统的问题，它可以在体内引起的性能问题。

所以选择让你这样，退休的担忧。多少tempdb文件是正确的吗我不能给你答案，但根据我多年的咨询经验和经验来参加会议，我可以给你一个指导解决tempdb创建多个文件要小心闩锁争用，如果它只能增加tempdb文件，你需要做的可伸缩性和性能之间的平衡。

我希望上面的指导会对你有所帮助。

PS：回应一些评论：tempdb文件没有必要被分布在多个记忆。如果你看到一个pagelatch型的等待，即使你是分布不提高性能，如果pageiolatch等等，也许你需要更多的内存，但这不一定是你需要告诉tempdb转移到另一个存储系统，而不只是添加一个文件tempdb。这就需要你对其进行详细的分析后再做决定。