SQL Server通常都運行在多處理器的服務器上，這一點在現在尤為普遍。原因是多內核的處理器越來越普及。那么，在多處理器環境下，Windows操作系統(事實上是從2000開始的)通常都會將進程任務放在一個隊伍里面，然后讓這些處理任務依次去占有處理器進行計算。

這樣做的好處就是每個計算任務都可以獲得近似于平均的處理資源，盡管無法保證一個處理任務每次都能拿到同一個處理器。這就像嘉年華我們重復排隊參加一個刺激的項目(比如說自由落體，事實上我從來不參加這種項目)，每個人上去一輪，并不能保證每次都能做同一張位置。

不過回到SQL Server上面來，SQL Server可不喜歡這樣的處理機制。

大家可能都知道處理器中有個東西叫片內緩存，片內緩存有1級、2級、3級之分。

我們假設處理器要計算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中調度這個概念)。