SQL Server通常都运行在多处理器的服务器上，这一点在现在尤为普遍。原因是多内核的处理器越来越普及。
那么，在多处理器环境下，Windows操作系统(事实上是从2000开始的)通常都会将进程任务放在一个队伍里面，然后让这些处理任务依次去占有处理器进行计算。
这样做的好处就是每个计算任务都可以获得近似于平均的处理资源，尽管无法保证一个处理任务每次都能拿到同一个处理器。这就像嘉年华我们重复排队参加一个刺激的项目(比如说自由落体，事实上我从来不参加这种项目)，每个人上去一轮，并不能保证每次都能做同一张位置。
不过回到SQL Server上面来，SQL Server可不喜欢这样的处理机制。
大家可能都知道处理器中有个东西叫片内缓存，片内缓存有1级、2级、3级之分。
0vJ o9E4 I?,g3v _8o14943301我们假设处理器要计算A、B、C三个任务，处理器先运算A任务，A任务还没有结束的时候它的游戏时间就结束了，因此处理器在接受B的时候会将计算B所需的数据加载到1级片内缓存中，而将A任务(我们假设处理器还没有完成它的计算任务)的数据挪到2级片内缓存中，或者3级。
当那个A任务回来的计算的时候，处理器会从2级片内缓存中恢复计算所需的数据，当然这要取决于是不是那些数据还在2级缓存中，因为有很多因素可以让它不在那儿，比如说A任务回来的时候发现接待它的已经不是原来那个处理器了，当然A任务就不能指望面前这个处理器有它的计算数据了(当然计算A任务回到同一颗处理器，也可能因为其他任务占用了这个处理器的2级片内缓存而导致它原来存入的数据被替换掉了)。
如果处理器发现A任务数据还在2级片内缓存中，操作系统就认为这次命中了2级缓存，如果不在了，就说这次没有命中2级缓存。因此我们可以知道操作系统是非常渴望每次都命中2级缓存的，因为这样就可以节省不少时间重新从内存中将数据加载到片内缓存中。
大多数操作系统要面对的任务都不会有太多的计算数据，因此这些任务不需要太多关心片内缓存的问题。同时多数低端的服务器也没有很大的片内缓存，因此它们也不太关心这个问题。不过对于运行在有较大片内缓存的服务器上的SQL Server来说，这个问题就要严肃一些了。
在中高端的PC服务器(为什么说是PC服务器呢，因为Windows现在还可以运行在一些厂商的小型机平台上，例如HP的SuperDome)中，通常单个处理器的片内缓存都在2M-4M，而且这些服务器可以拥有8个甚至更多一些的处理器，同时SQL Server的计算任务都是依赖于大量数据的，因此SQL Server的一个任务可不希望它重新拿回处理器的时候发现自己的数据不在了。
为了解决这个问题，SQL Server就有了这个处理器亲和度(Processor Affinity)的配置项，启用这个选项后，SQL Server中的任务就会记着自己原来在那个处理器上工作的，当它们再次有机会回到处理器工作的时候它们会认准回家的路——只用原来的那颗处理器。(事实上这个过程要复杂一些，有兴趣的朋友可以进一步了解SQL Server中调度这个概念)。