SQL SERVER 的SQL語句優化方法小結。本站提示廣大學習愛好者：（SQL SERVER 的SQL語句優化方法小結）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL SERVER 的SQL語句優化方法小結正文
1、SQL SERVER 2005的機能對象中有SQL Server Profiler和數據庫引擎優化參謀，極好的東東，必需闇練應用。
2、查詢SQL語句時翻開“顯示估量的履行籌劃”，剖析每一個步調的情形
3、低級做法，在CPU占用率高的時刻，翻開SQL Server Profiler運轉，將跑上去的數據存到文件中，然後翻開數據庫引擎優化參謀挪用誰人文件停止剖析，由SQL SERVER供給索引優化建議。采用它的INDEX索引優化部門。
4、但下面的做法常常不會跑出你所須要的，在比來的優化進程中CPU占用率極高，但基本提不出我須要的優化建議，特殊是有些語句是在存儲進程中而且多表聯立。這時候就須要用中級做法來定位占用CPU高的語句。
5、照樣運轉SQL Server Profiler，將運轉成果保留到某個庫的新表中（隨意起個名字體系會本身建）。讓它運轉一段時光，然後可以用
select top 100 * from test where textdata is not null order by duration desc
這個可以選出運轉時光長的語句，在ORDER BY 中可以調換成CPU、READS，來選出CPU占用時光長和讀數據過量的語句。
定位出成績的語句以後便可以詳細剖析了。有些語句在履行籌劃中很顯著可以看出成績地點。
罕見的有無建索引或索引樹立不公道，會湧現table scan或index scan，但凡看到SCAN，就意味著會做全表或全索引掃描，這是帶來的必定是讀次數過量。我們希冀看到的是seek或鍵查找。
6、怎樣看SQL語句履行的籌劃很有講求，初學者會過於存眷外面顯示的開支比例，而現實上這個有時會誤導。我在現實優化進程中就被發明，一個index scan的履行項開支只占25%，另外一個鍵查找的開支占50%，而鍵查找部門基本沒有可優化的，SEEK謂詞就是ID=XXX這個樹立在主鍵上的查找。而細心剖析可以看到，後者CPU開支0.00015，I/O開支0.0013。而前者呢，CPU開支1.4xxxx,I/O開支也弘遠於後者。是以，優化重點應當放在前者。
7、若何優化單個部門，一個龐雜的SQL語句，SQL SERVER會很聰慧地重組WHERE後的語句，試圖婚配索引。選中帶優化的步調，選擇旁邊的‘屬性”，再選擇個中的“謂詞”，將個中部門復制上去，這部門就是分化後的WHERE 語句，然後在查詢界面中select * from 表 where 適才復制上去的“謂詞”。這個就是須要優化的部門，既然曾經走到這一步了，年夜部門人應當妙手動樹立索引了，由於這裡的WHERE語句比之前的確定簡略很多。（在我項目華夏始SELECT語句的WHERE部門有10個前提組合，觸及6個字段，提掏出來要優化的部門就4個前提，觸及到3個字段。新的索引樹立後，CPU占用率一會兒就下降了，並且新樹立的索引觸及的字段屬於不常UPDATE的部門，頻仍的讀寫操作不會影響UPDATE的效力）
8、以上就是優化的思緒，最初提一些優化進程或是體系設計時中須要留意的成績。
A、盡可能防止用select * from xxx where abc like '%xxx'類型的隱約查詢，由於%在後面的話是沒法應用到索引，必定會惹起全量SCAN操作。應當找尋替換方法或用前置前提語句把like查找之前的行數減到最低。
B、盡可能防止對年夜表數據停止select top n * from xxx where xxxx order by newid()的取隨機記載的操作。newid()操作會讀全量數據後再排序。也會占用年夜量CPU和讀操作。可以斟酌用RAND()函數來完成，這方面我還在研討中，關於整表操作比擬好弄，好比id>=(select max(id) from table)*rand()。但假如取部分數據的隨機記載還須要考慮。
C、在SQL Server Profiler記載中會看到Audit Logout會占用年夜量CPU和讀寫等操作。查了一些材料稱是某個鏈接在某次銜接進程中履行SQL語句發生的總數，不消過於擔憂。看上去切實其實仿佛如許，許多Audit Logout的CPU和IO消費量和之前優化的語句根本分歧。所以在第5點我提的SQL語句用textdata is not null前提把Audit Logout給隱去。
D、兩個分歧字段OR語句會招致全表掃描。例如 where m=1 or n=1。假如樹立一個索引是m和n，異樣會惹起scan，處理辦法是給m和n分離樹立索引。測試12萬條數據的表，索引樹立毛病的情形下IO開支高達 10.xxx，分離樹立索引後，全體釀成0.003，這個反差長短常偉大的。固然會惹起INSERT操作的機能成績，但究竟年夜部門瓶頸在SELECT的讀操作上。
E、索引查找（Index Seek)和索引掃描(Index Scan)，我們須要的是前者，而惹起後者的緣由平日是某個索引裡的字段過剩要查找的，例如索引樹立在A和B兩個字段，而我們只需查找A，則會招致 INDEX SCAN。建議針對零丁的A樹立索引，以構成索引查找。
F、關於小表不建議樹立索引，特殊是幾百的數據量，只要上千上萬級其余數據樹立索引才有用果。
數據庫優化是很深的學問，在數據庫設計時就應當留意，特殊是最初提到的A、B兩點，盡量在設計早期防止。
