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

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

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

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

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

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

如何監控CPU對列（CPU queuing）

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

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

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

通過內存和CPU進行SQL Server性能調優