說起SQL SERVER的調優，我想大伙也很想知道這方面的知識。本人也正在探索的路上，大家有什麼好 的意見，歡迎一起探討、研究。博取眾人之長，才能揚長避短。
本文中的內容主要是摘自《程序員的 SQL金典》，如若大家想拜讀，可在網上下載拜讀（當然最好的方式還是購買作者的書）。
關於調優 的方案，有涉及硬件方面的知識，也有涉及軟件方面的知識。但本人只是個軟件方面的IT男，所以只是 記錄軟件方面的內容。
其實關於SQL SERVER或者是其它數據庫來講，有些優化手段都是一致的。比如 常規的方式有如下幾種方式：
創建必要的索引
大學讀書時就聽說過數據庫裡面的索引，一直沒去深究過，也在無知無畏中進行了四年多的開發生涯 ，想來慚愧的很，今天有幸了解，頓感人生之闊然開朗一般。索引，不單是數據庫裡面才有，像我們寫 代碼不也碰到數組也有索引嘛。索引就是已經按照某一種固定好的方式排序好內容，然後我們再去通過 索引位置來定位到它。說到SQL SERVER的索引，有必要講講兩個概念。分別是聚簇索引和非聚簇索引。
1、聚簇索引：就是索引存儲的方式跟內容物理存儲的方式一致
2、非聚簇索引：就是索引存儲的 方式跟內容物理存儲的順序不一致
下面簡單說明兩者的區別。最簡單的例子就是漢語詞典的方式，對 於一本漢語詞典來說，它的物理存儲順序是已經固定好了的，是通過拼音的順序排列好的，這也就是說 ，漢語詞典的物理存儲方式就是通過拼音的方式來存儲。比如以拼音來建立的索引，就是聚簇索引。WHY ？因為索引的存儲跟漢語詞典的物理存儲是一致的，也就是上面概念所說的分類。那麼非聚簇索引是什 麼情況，比如像漢語詞典裡面偏旁部首是一種索引的話，那麼偏旁部首的索引就會是非聚簇索引了。WHY ？因為它跟漢語詞典原有的物理存儲方式不一致。當創建聚簇索引時需要每一張表只能有一個聚簇索引 ，因為表中數據的物理順序只能有一個，而非聚集索引則可以創建多個。
注：由於索引需要占據一定的存儲空間，而且索引也會降低數據插入、更新和刪除的速度，所以應該 只創建必要的索引，一般是在檢索的字段創建索引。 對於刪除來說，索引會造成碎片的問題。因為當我 們刪除一條記錄的時候，對應的索引並不會刪除。造成創建的索引被閒置，一旦閒置的索引碎片多了， 就會影響查詢的效率。系統的垃圾碎片也是一樣的道理，需要定期清除。對於索引來說，發現使用索引 搜索的速度慢了，就需要定期去重建索引，重建索引將會先刪除之前創建的索引，然後再新建新的索引 ，主流數據庫管理系統都提供了重建索引的功能。
使用預編譯查詢
很多人會使用存儲過程把SQL語句預先編譯起來，以此來達到優化的目的。有的項目是根據用戶的輸 入來動態執行SQL語句，不管何種方式，都使用參數化的方式來執行，這樣不僅可以避免SQL注入漏洞攻 擊，最重要數據庫會對這些參數化SQL執行預編譯，這樣第一次執行的時候DBMS會為這個SQL語句進行查 詢優化並且執行預編譯，這樣以後再執行這個SQL 的時候就直接使用預編譯的結果，這樣可以大大提高 執行的速度。
調整WHERE 子句中的連接順序（這個不是很懂？）
DBMS 一般采用自下而上的順序解析WHERE 子句，根據這個原理,表連接最好寫在其他WHERE條件之前 ，那些可以過濾掉最大數量記錄。
比如下面的SQL語句性能較差：
SELECT * FROM T_Person WHERE FSalary > 50000 AND FPosition= ‘MANAGER’ AND 25 < (SELECT COUNT(*) FROM T_Manager WHERE FManagerId=2);
我們將子查詢的條件放到最前面，下面的SQL語句性能比較好：
SELECT * FROM T_Person WHERE < (SELECT COUNT(*) FROM T_Manager WHERE FManagerId=2) AND FSalary > 50000 AND FPosition= ‘MANAGER’ ;
SELECT語句中避免使用'*'
對於SELECT * FROM TABLE這種方式，我想很多人都會這麼去查詢。WHY？一方面是因為系統的數據量 級別還比較低，二來也圖方便。但是隨著項目的數據量瘋長，系統的性能急速下降之後，優化的每一種 方式都需要引起我們的重視。像查詢這種方式來講，如果不用檢索出所有列的情況，盡量指定查詢的列 。這能有效減輕網絡的負載和服務器資源的消耗。即使確實需要檢索所有列，也不要使用SELECT *，因 為這是一個非常低效的方法，DBMS在解析的過程中，會將*依次轉換成所有的列名，這意味著將耗費更多 的時間。在SQL Server Management Studio工具裡面查詢圖省事，數據量不大我覺得還是可以的:)，但 至少在代碼裡面是不建議這麼處理。
多條SQL語句壓縮到一句SQL中去執行
對於SQL語句的執行，每次都要建立網絡連接、進行權限校驗、進行SQL語句的查詢優化、發送執行結 果，這個過程是非常耗時的，因此應該盡量避免過多的執行SQL語句，能夠壓縮到一句SQL執行的語句就 不要用多條來執行。
用Where子句替換HAVING 子句
避免使用HAVING 子句，因為HAVING 只會在檢索出所有記錄之後才對結果集進行過濾。如果能通過 WHERE 子句限制記錄的數目，那就能減少這方面的開銷。HAVING 中的條件一般用於聚合函數的過濾，除 此而外，應該將條件寫在WHERE 子句中。
