tempdb大量闩锁等待问题分析

背景

客户业务系统升级后，高峰期运行缓慢，在SQL专家云上看到数据库出现严重等待，需要分析原因并紧急处理。

现象

登录到SQL专家云中，进入实时可视化页面，在活动会话里面看到有大量资源等待的会话。

点击一个时间点，进入到该时间点的活动会话原始数据。看到大量会话的等待类型为PAGELATCH_UP，等待资源为“2：1：xxxxxxx” ，SQL语句都和临时表有关。

分析

会话等待的资源“2：1：xxxxxxx” 代表ID为 2 的数据库（tempdb）的1号文件（tempdev）的xxxxxxx页。SQL语句创建一个临时表时，相当于在tempdb中创建一张表，SQL Server要为这张表分配存储页面，需要修改SGAM、PFS、GAM系统数据页，为了其他表不会分配到同一个数据页，在修改时使用闩锁，修改完成后释放闩锁。

这种机制对一般的用户数据库不会有问题，因为正常的应用不会折腾着不停地建表、删表。但是tempdb就不同了，经常会有高并发的SQL语句使用临时表。因此在同一个时间点会有很多线程要修改系统页，就会产生大量的PAGELATCH_UP闩锁等待。