?　　SQL Server內(nèi)存還會影響性能，而如果在SQL Server系統(tǒng)中有太多的內(nèi)存就是浪費錢，內(nèi)存太少就又對性能十分有害。遺憾的是，決定你什么時候在系統(tǒng)里需要更多的內(nèi)存很靈活。當內(nèi)存出現(xiàn)問題時，你就會發(fā)現(xiàn)disk I/O就會增加，同樣磁盤列隊也會增加。你也會發(fā)現(xiàn)buffer cache hit ratio減少、page life會延長。隨著內(nèi)存需求的增加，你就會開始發(fā)現(xiàn)日志文件里的錯誤信息。

　　SQL Server內(nèi)存的一個重要部分已經(jīng)分開了，這樣一來就造成了性能退化。持續(xù)時間：%n秒、工作組(KB)：%w、committed (KB):：%c、內(nèi)存利用：%u。

　　SQL Server遇到了%o IO請求事件用15秒以上的時間在數(shù)據(jù)庫[%d] (%i)里的[%f]文件上完成。OS文件處理為%h。偏移的最新IO 長度為: %l.。

　　但是這并不是這些錯誤被報告的唯一的一次，所以你需要和性能監(jiān)控器metric一起使用來測定內(nèi)存是否真的太低。

　　在處理SQL Server內(nèi)存問題方面也有一些解決辦法，最簡單的就是解決辦法就是擴大服務(wù)器內(nèi)存增加可使用的buffer cache的數(shù)量。這樣做就增加了內(nèi)存數(shù)據(jù)量、減少了你的disk I/O。其他的解決辦法包括遷移大空間表的集群式索引以及只使用這些表的非集群式的索引，包括Primary Key。

　　在集群式索引用于查找并且使用了集群式的index seeks時就不同了。如果使用了另一個索引，它就不可能減輕任何內(nèi)存壓力，因為集群式的索引并沒有在內(nèi)存里。如果使用了集群式的index scans，那么在不遷移索引的情況下一個新的非集群式的索引可能會有用。

如何監(jiān)控CPU對列（CPU queuing）

　　CPU是硬件的另一個部分，它能夠?qū)е聺撛诘男阅軉栴}。大多數(shù)人只看CPU的速度或數(shù)量。然而就如同磁盤一樣，CPU能夠成為瓶頸。如果出現(xiàn)了CPU瓶頸，你可能100%不會去查看CPU的性能。CPU擁有命令對列的方式就如同I/O對列一樣。命令被下載到CPU隊列中，并且執(zhí)行之前的操作程序等待CPU變得可以使用。由于CPU的速度變得更快了，我們在CPU里面做任何事情的速度也就加快了，但是我們一次也只能做同樣多的事情。現(xiàn)在我們可以使用雙核、三核、四核以及多核的CPU。這樣我們一次能夠執(zhí)行更多的命令。

　　你可以利用SQL Server性能監(jiān)控器監(jiān)控你的CPU。你會在System目標下面發(fā)現(xiàn)PerfMon，它有一個計算器的名字“處理機隊列長度”。幾乎任何其他大于零的隊列長度都表明你需要增加一些操作程序，這些操作程序是SQL Server都能同時執(zhí)行的。但是這并不表明需要一個更快的CPU，而是需要一個更多核的CPU。今天最新的服務(wù)器每臺服務(wù)器都支持32核，一些高級的服務(wù)器支持64核（當chase按比例范圍共同支持64核時）也可以創(chuàng)建（僅僅是某些廠商）。

　　在第一部分和第二部分里，我已經(jīng)指出了硬件里的一些地方。這些技巧不是解決性能問題最全面的、最終的解決方案。表的設(shè)計和索引的調(diào)整經(jīng)常是并且長期是非常重要的。今天的SQL Server有望在更長的時間內(nèi)做更多的事情，這樣才能使硬件調(diào)整對數(shù)據(jù)庫平臺更加重要。用arsenal里的一些工具解決性能問題，這樣你就能從還未或已經(jīng)行最小限度升級的現(xiàn)存的每項硬件性能。但是當你的確需要購買時，這些技巧有助于你作出正確的決策，做到物有所值。

通過內(nèi)存和CPU進行SQL Server性能調(diào)優(yōu)