在SQL Server的世界中,SQL Server在Windows之上有一套自己的任务调度和资源分配系统,这使得SQL Server作为Windows的一个进程,却可以处理大量的并发,这些任务调度和资源分配非常像一个操作系统,因此SQL Server在Windows之上,有一层被称为SQL OS的系统。

  类似Windows进程之间的任务调度,SQL Server OS也有一套自己的调度方案,在早期的SQL Server曾经使用Windows自带的进程调度系统,但由于SQL Server是一个处理高并发的进程,因此Windows调度造成的线程切换(Context Switch)会带来很多的资源浪费,并且Windows调度是抢占式调度,这对于SQL Server来说非常不利,因此SQL Server OS通过非抢占式调度算法来调度进程,除非线程自己释放资源,SQL Server不会强制剥夺资源(当然了,一些极端情况比如死锁,或是检查scheduler时发现不利问题,会记录到日志,但依然不会抢占资源),这也使得开发人员对T-SQL语句需要小心,当然了这是题外话了。

  在了解了SQL Server基本的调度算法后,再让我们通过一个图来了解一下简单的SQL Server中线程的几种状态(这类线程对Windows来说是线程,对SQL Server来说是进程,这也是为什么查询这些线程的时候用的是Sysprocess),如图所示。

SQL Server OS的简单算法

  如果你了解操作系统的调度算法的话,你会发现这里和操作系统的形式一样,当线程得到等待的资源并获得CPU时,会是运行状态,而当获得资源没有CPU时,会是Runnable状态,或是当线程所需的资源没有到位时,会是阻塞状态。

  因此,多个CPU可以有多个线程在Running状态。

  另外在SQL Server中,每创建一个新表时,都会为表分配存储页面,相应的,SQL Server也需要修改GAM,SGAM和FPS页。对于修改这些页来说,SQL Server需要在修改的时候加上一个轻量级的锁,这也是所谓的闩锁(Latch)。当多个线程同时需要修改GAM,SGAM,FPS页时,闩锁会造成阻塞。对于用户数据库来说,不可能一直存在DDL操作,但对于Tempdb来说,会经常进行建表和删表,因此对于GAM,SGAM以及FPS页都会经常修改,如果Tempdb只有一个文件而CPU存在多核的时候,多个同时运行的任务有可能争抢GAM,SGAM,FPS页的修改权,因此造成阻塞,这对性能是非常不利的,而按照CPU个数将TempDB的文件分为多份,则会存在多个GAM,SGAM,FPS页。多个Running的线程会按照每个文件的大小平均分布到不同的文件中,因此解决了争用问题。

  另外,值得注意的是,对于TempDB的佳做法是一开始为每一个文件分配足够大的值。并且每个文件大小相等,这避免了某个文件增长导致的文件大小不一,而SQL Server对于文件的使用比率是按照文件大小,如果文件大小不一样,会造成热点文件,从而有可能造成闩锁争用。