Step 1. TempDB pressure diagnosis

Wait Type Diagnosis

The contention pressure of TempDB has been briefly introduced in the waiting chapter. The waiting performance is pagelatch_ class waiting, and the waiting resource is "2:X:X"

Response time of the disk where tempDB is located

There is only one tempdb under one instance, that is, when you create 100 databases under one instance, these 100 databases can only use this one tempdb.

Tempdb is required for temporary tables you create, or for operations such as sorting required by SQL execution statements. Therefore, TempDB has relatively high requirements on the response time of the disk.

Step 2. Fix the problem

Set TempDB to multiple to distribute this pressure.

split into multiple files

　　　　As a general rule, if the number of logical processors is less than or equal to 8, use the same number of data files as there are logical processors. If the number of logical processors is greater than 8, use 8 datafiles , then if contention still exists, increase the number of datafiles by a multiple of 4 (maximum number of logical processors) until the contention is reduced to an acceptable level or the workload /code to make changes.

The file size and growth rate should be the same

　　　There is a small detail to pay attention to here, the files you allocate must be the same size , and if you set automatic growth, the growth rate must be the same .

TempDB disk partitioning

　　 In most cases, the files of TempDB do not need to be split on the disk, they can be on the same disk. If the pressure is high, you can choose to place them on a separate disk, so that there will be no disk resource competition with other files (such as data read and write). .

　　　　If the read response time of TempDB is high, please consider the disk-related optimization of TempDB, such as placing the TempDB file separately on a faster disk.

Step 3. Statement Tuning

　　The statement tuning article mentioned that the use of temporary tables or table changes in the statement will reduce the complexity of the statement and improve the efficiency of the statement. If the statement is overused, it will cause the pressure on TempDB mentioned in the article. So how to balance it? Here are some suggestions:

切记不要过度使用临时表！临时表的使用主要有两个场景，拆分语句降低复杂性。另一个是缓存中间结果避免重复操作。
减少使用临时表锁系统表的时间！”select 字段 into #临时表 from“ 如果语句执行时间过长这将是灾难，尽量选用先创建，后插入的做法。

原理：TempDB压力从哪来？

　　　　当数据库创建一张新表的时候，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页面）！

　　　　这里关于系统页不过多的介绍，想详细了解的朋友请参见： SQL Server中的GAM页和SGAM页

我创建个临时表跟系统页还有关系？

　　　　下面也用一个例子说明：

　　　　创建临时表的时候会对系统表中进行插入和更新，而删除临时表逆向过程会删除或更新系统表！

use [AdventureWorks2012]
GO
checkpoint
go
create table #t
(
id int
)
drop table #t


use tempdb
go
select Operation,CONTEXT,[Transaction ID],AllocUnitId,AllocUnitName,[Page ID],[Transaction Name],Description from fn_dblog(null,null)

　　　　所以当你并发过高且频繁创建删除临时表的时候就会造成大量的争用。

SQL SERVER - How to quickly locate problems with TempDB