此时，无需重启实例就能看到4个Scheduler被Offline，如图3所示：

图3.在线Offline 4个Scheduler

　　一般来说，除非您的服务器上运行其他实例或程序，否则不需要控制Affinity。

　　在图1中，我们还注意到，除了Visible的Scheduler之外，还有一些特殊的Scheduler，这些Scheduler的ID都大于255，这类Scheduler都用于系统内部使用，比如说资源管理、DAC、备份还原操作等。另外，虽然Scheduler和逻辑CPU的个数一致，但这并不意味着Scheduler和固定的逻辑CPU相绑定，而是Scheduler可以在任何CPU上运行，只有您设置了Affinity Mask之后，Scheduler才会被固定在某个CPU上。这样的一个好处是，当一个Scheduler非常繁忙时，可能不会导致只有一个物理CPU繁忙，因为Scheduler会在多个CPU之间移动，从而使得CPU的使用倾向于平均。

　　这意味着对于一个比较长的查询，可以前半部分在CPU0上执行，而后半部分在CPU1上执行。

　　另外，在每一个Scheduler上，同一时间只能有一个Worker运行，所有的资源都就绪但没有拿到Scheduler，那么这个Worker就处于Runnable状态。下面让我们来看一看Worker。

　　Worker

　　每一个Worker可以看做是对应一个线程（或纤程），Scheduler不会直接调度线程，而是调度Worker。Worker会随着负载的增加而增加，换句话说，Worker是按需增加，直到增加到最大数字。在SQL Server中，默认的Worker最大数是由SQL Server进行管理的。根据32位还是64位，以及CPU的数量来设置最大Worker,具体的计算公式，您可以参阅BOL：http://msdn.microsoft.com/zh-cn/library/ms187024(v=sql.105).aspx。当然您也可以设置最大Worker数量，如图4所示。

图4.设置最大Worker数量

　　如果是自动配置，那么SQL Server的最大工作线程数量可以在sys.dm_os_sys_info中看到，如图5所示。

图5.查看自动配置的最大Worker数量