導讀:1建站知識TempDB的文件沒有必要分布在多個存儲器之間。如果你看到PAGELATCH類型的等待，即使你進行了分布也不會改善性能，而seo網站優化培訓網seo優化趨勢。

誤區 #12:TempDB的文件數和需要和CPU數目保持一致

錯誤

哎，由于上述誤區是微軟“官方”的建議，并且還有大量博文堅持這個觀點，這個誤區已經是老生常談。

但讓seo網站優化人困惑的是SQL CAT團隊給出的建議就是1：1，但這個建議是源自擴展方面的原理來說,而不是一個通用法則。因為他們所面對的大型客戶數據量服務器和IO子系統都是大部分人沒有機會遇到的。

每個實例僅僅允許有一個TempDb,但需要用到TempDB的地方卻有很多，所以TempDB很容易成為性能瓶頸，我想大家數人都了解這一點，而大多數人所不了解的應該是在什么情況下才需要額外的TempDB文件。

當你看到PAGELATCH類型的阻塞時，說明遇到內存中分配位圖的爭用問題了。而看到PAGEIOLATCH，說明遇到I/O子系統層面的爭用問題了。對于閂鎖（Latch）你可以將其看網站建設多少錢作和普通鎖是一種東西，但更輕量,更短，并且只會被存儲引擎內部使用。

MVP Glenn Berry 有一篇博文里有查看sys.dm_os_wait_stats的DMV。這篇博文中可以查到你的服務器造成阻塞最多的原因是什么。如果你發現是PAGELATCH型等待，你可以使用這段腳本來查看是由于FPS,GAM還是SGAM爭用造成的問題。

如果你遇到閂鎖爭用，可以通過跟蹤標記1118或是多建一個TempDB文件來緩和這個狀況(原理可以在知識庫KB 328551查到),我已經寫了一篇關于為什么追蹤標記1118依然被需要的長博文，鏈接：Misconceptions around TF 1118。

如何seo優化推廣網站 在SQL SERVER 2000時代，TempDB的文件數需要和CPU核數保持1：1的關系，在SQL SERVER 2005和2008版本這條建議也適用，但由于SQL SERVER 2005+后的優化措施(詳細請看我的博文),你不再需要嚴格按照1：1的比例關系設置CPU核數和TempDB文件數，而是文件數和CPU核數的比例保持在1:2或是1:4就行了。

[題外話：在SQL PASS 2011我的好朋友Bob Ward,也是SQL CSS最牛的人。給出了一個新的公式:如果CPU核數小于等于8，使其比例保持在1:1,而如果CPU核數大于8，使用8個文件，當你發現閂鎖爭用現象時，每次額外加4個文件]

不過這也不能一概而論。上周我遇到一個問題，一個客戶的TempDB負載大到需要32個CPU配上64個TempDB文件才能減輕閂鎖爭用。這是否意味著這是一個最佳實踐呢？當然不是。

那你或許有疑問，為什么1:1的比例不好呢，那是因為太多的TempDB有可能引起另一個性能問題。如果你的一條查詢中某些操作（比如排序）需要使用大量的內存，但內存不夠時，就需要將這些內容分配到TempDB中。當存在多個TempDB文件時,由于TempDB的循環分配機制,這有可能導致性能被拖累，對于比較大的臨時表也是如此。

關鍵詞標簽: 誤區 標簽 SQL