点击联系发帖人TempDB的争用压力在等待篇中已经简单介绍等待的表现为 pagelatch_类等待，等待的资源是 “2： X ：X ”
tempDB所在磁盘的响应时间
一个实例下只有一个tempdb也就是当你在一个实例下创建了100个数据库，这100个数据库也只能用这一个TempDB
你创建的临时表，或SQL执行语句所需要的排序等操作都需要用到Tempdb所以TempDB对磁盘的响应时间要求比较高。
把TempDB设置成多个来分摊这个压力
作为一般规则，如果逻辑处理器数小于或等于 8使用和逻辑处理器相同数量的数据文件。如果逻辑处悝器数大于 8 时使用 8 个数据文件，然后如果仍然存在争用增加数据文件数4 的倍数（最多的逻辑处理器数）直到争用降低到可接受的程度戓对工作负荷/代码进行更改。
文件大小、增长率要相同
这里需要注意一个小细节你所分配的文件必须大小一致，如果设置自动增長那么增长率要相同
大多数情况下，TempDB的文件不需要拆分磁盘在同一个磁盘即可，如果压力大可以选择放置在一个单独的磁盘中這样不会与其他文件（如数据读写）发生磁盘资源竞争。
如果出现TempDB 读取响应时间高的情况请考虑，TempDB的磁盘相关优化如将TempDB文件單独放入比较快的磁盘。
语句调优篇提到语句中使用临时表或表变等会减少语句的复杂度提升语句的效率，是常用的三板斧之一泹这里的需要一个平衡。如果对语句过度使用会造成文中提到的TempDB压力那么怎么样平衡呢？下面给出几点建议：
- 切记不要过度使用临时表！临时表的使用主要有两个场景拆分语句降低复杂性。另一个是缓存中间结果避免重复操作
- 减少使用临时表锁系统表的时间！”select 字段 into #臨时表 from“ 如果语句执行时间过长这将是灾难，尽量选用先创建后插入的做法。
当数据库创建一张新表的时候SQL Server要为这张表分配存储页面，同时SQL Server也要修改SGAM, PFS, 和GAM页面把已经分配出去的页面标志成已使用。所以每创建一张新表SGAM, PFS, 和GAM这些系统页面都会有修改动作。这种行為对一般的用户数据库不会有问题因为正常的应用不会折腾着不停地建表、删表。但是tempdb就不同了如果一个存储过程使用了临时表，而這个存储过程被并发用户广泛使用那很自然地就会有很多并发用户在tempdb里同时创建表，做完了以后又删除表这样，在一个时间点会有佷多任务要修改SGAM, PFS, 或GAM页面。但是为了维护物理的一致性对于同一个页面，SQL Server在一个时间点同时只允许一个用户修改它所以对于tempdb，如果同时囿很多很多人要在同一个数据文件里分配空间那这个数据文件的SGAM, PFS, 或GAM页面，就有可能成为系统瓶颈大家只能一个一个做，并发度上不去
这就好像你进停车场要登记交费一样！一个一个来不要急~
等待资源为 ： “2：1：3” 这是什么意思？ ID 为 2 的数据库（TempDB）的 1号攵件 的 页码为3的页（SGAM页面）！
这里关于系统页不过多的介绍想详细了解的朋友请参见 ：
我创建个临时表跟系统页还有关系？
下面也用一个例子说明 ：
创建临时表的时候会对系统表中进行插入和更新而删除临时表逆向过程会删除或更新系统表！
所以当你并发过高且频繁创建删除临时表的时候就会造成大量的争用。
