SQL SERVER 的SQL語句優(yōu)化方式小結(jié)
更新時間:2009年08月05日 23:12:04 作者:
千辛萬苦,終于把數(shù)據(jù)庫服務(wù)器的CPU從超過50%(開5個程序線程)乃至100%(開10個程序線程)降低到了5%。摸索到了一些門道,總結(jié)一下
1、SQL SERVER 2005的性能工具中有SQL Server Profiler和數(shù)據(jù)庫引擎優(yōu)化顧問,極好的東東,必須熟練使用。
2、查詢SQL語句時打開“顯示估計的執(zhí)行計劃”,分析每個步驟的情況
3、初級做法,在CPU占用率高的時候,打開SQL Server Profiler運行,將跑下來的數(shù)據(jù)存到文件中,然后打開數(shù)據(jù)庫引擎優(yōu)化顧問調(diào)用那個文件進行分析,由SQL SERVER提供索引優(yōu)化建議。采納它的INDEX索引優(yōu)化部分。
4、但上面的做法經(jīng)常不會跑出你所需要的,在最近的優(yōu)化過程中CPU占用率極高,但根本提不出我需要的優(yōu)化建議,特別是有些語句是在存儲過程中并且多表聯(lián)立。這時就需要用中級做法來定位占用CPU高的語句。
5、還是運行SQL Server Profiler,將運行結(jié)果保存到某個庫的新表中(隨便起個名字系統(tǒng)會自己建)。讓它運行一段時間,然后可以用
select top 100 * from test where textdata is not null order by duration desc
這個可以選出運行時間長的語句,在ORDER BY 中可以替換成CPU、READS,來選出CPU占用時間長和讀數(shù)據(jù)過多的語句。
定位出問題的語句之后就可以具體分析了。有些語句在執(zhí)行計劃中很明顯可以看出問題所在。
常見的有沒有建索引或索引建立不合理,會出現(xiàn)table scan或index scan,凡是看到SCAN,就意味著會做全表或全索引掃描,這是帶來的必然是讀次數(shù)過多。我們期望看到的是seek或鍵查找。
6、怎么看SQL語句執(zhí)行的計劃很有講究,初學者會過于關(guān)注里面顯示的開銷比例,而實際上這個有時會誤導(dǎo)。我在實際優(yōu)化過程中就被發(fā)現(xiàn),一個index scan的執(zhí)行項開銷只占25%,另一個鍵查找的開銷占50%,而鍵查找部分根本沒有可優(yōu)化的,SEEK謂詞就是ID=XXX這個建立在主鍵上的查找。而仔細分析可以看到,后者CPU開銷0.00015,I/O開銷0.0013。而前者呢,CPU開銷1.4xxxx,I/O開銷也遠大于后者。因此,優(yōu)化重點應(yīng)該放在前者。
7、如何優(yōu)化單個部分,一個復(fù)雜的SQL語句,SQL SERVER會很聰明地重組WHERE后的語句,試圖匹配索引。選中帶優(yōu)化的步驟,選擇旁邊的‘屬性”,再選擇其中的“謂詞”,將其中部分復(fù)制下來,這部分就是分解后的WHERE 語句,然后在查詢界面中select * from 表 where 剛才復(fù)制下來的“謂詞”。這個就是需要優(yōu)化的部分,既然已經(jīng)走到這一步了,大部分人應(yīng)該能手動建立索引了,因為這里的WHERE語句比之前的肯定簡單不少。(在我項目中原始SELECT語句的WHERE部分有10個條件組合,涉及6個字段,提取出來要優(yōu)化的部分就4個條件,涉及到3個字段。新的索引建立后,CPU占用率一下子就降低了,而且新建立的索引涉及的字段屬于不常UPDATE的部分,頻繁的讀寫操作不會影響UPDATE的效率)
8、以上就是優(yōu)化的思路,最后提一些優(yōu)化過程或是系統(tǒng)設(shè)計時中需要注意的問題。
A、盡量避免用select * from xxx where abc like '%xxx'類型的模糊查詢,因為%在前面的話是無法利用到索引,必然會引起全量SCAN操作。應(yīng)該找尋替代方式或用前置條件語句把like查找之前的行數(shù)減到最低。
B、盡量避免對大表數(shù)據(jù)進行select top n * from xxx where xxxx order by newid()的取隨機記錄的操作。newid()操作會讀全量數(shù)據(jù)后再排序。也會占用大量CPU和讀操作??梢钥紤]用RAND()函數(shù)來實現(xiàn),這方面我還在研究中,對于整表操作比較好弄,比如id>=(select max(id) from table)*rand()。但如果取局部數(shù)據(jù)的隨機記錄還需要思量。
C、在SQL Server Profiler記錄中會看到Audit Logout會占用大量CPU和讀寫等操作。查了一些資料稱是某個鏈接在某次連接過程中執(zhí)行SQL語句產(chǎn)生的總數(shù),不用過于擔心??聪聛淼拇_似乎這樣,很多Audit Logout的CPU和IO消耗量和之前優(yōu)化的語句基本一致。所以在第5點我提的SQL語句用textdata is not null條件把Audit Logout給隱去。
D、兩個不同字段OR語句會導(dǎo)致全表掃描。例如 where m=1 or n=1。如果建立一個索引是m和n,同樣會引起scan,解決方法是給m和n分別建立索引。測試12萬條數(shù)據(jù)的表,索引建立錯誤的情況下IO開銷高達 10.xxx,分別建立索引后,全部變成0.003,這個反差是非常巨大的。雖然會引起INSERT操作的性能問題,但畢竟大部分瓶頸在SELECT的讀操作上。
E、索引查找(Index Seek)和索引掃描(Index Scan),我們需要的是前者,而引起后者的原因通常是某個索引里的字段多余要查找的,例如索引建立在A和B兩個字段,而我們只要查找A,則會導(dǎo)致 INDEX SCAN。建議針對單獨的A建立索引,以形成索引查找。
F、對于小表不建議建立索引,特別是幾百的數(shù)據(jù)量,只有上千上萬級別的數(shù)據(jù)建立索引才有效果。
數(shù)據(jù)庫優(yōu)化是很深的學問,在數(shù)據(jù)庫設(shè)計時就應(yīng)該注意,特別是最后提到的A、B兩點,盡可能在設(shè)計初期避免。
2、查詢SQL語句時打開“顯示估計的執(zhí)行計劃”,分析每個步驟的情況
3、初級做法,在CPU占用率高的時候,打開SQL Server Profiler運行,將跑下來的數(shù)據(jù)存到文件中,然后打開數(shù)據(jù)庫引擎優(yōu)化顧問調(diào)用那個文件進行分析,由SQL SERVER提供索引優(yōu)化建議。采納它的INDEX索引優(yōu)化部分。
4、但上面的做法經(jīng)常不會跑出你所需要的,在最近的優(yōu)化過程中CPU占用率極高,但根本提不出我需要的優(yōu)化建議,特別是有些語句是在存儲過程中并且多表聯(lián)立。這時就需要用中級做法來定位占用CPU高的語句。
5、還是運行SQL Server Profiler,將運行結(jié)果保存到某個庫的新表中(隨便起個名字系統(tǒng)會自己建)。讓它運行一段時間,然后可以用
select top 100 * from test where textdata is not null order by duration desc
這個可以選出運行時間長的語句,在ORDER BY 中可以替換成CPU、READS,來選出CPU占用時間長和讀數(shù)據(jù)過多的語句。
定位出問題的語句之后就可以具體分析了。有些語句在執(zhí)行計劃中很明顯可以看出問題所在。
常見的有沒有建索引或索引建立不合理,會出現(xiàn)table scan或index scan,凡是看到SCAN,就意味著會做全表或全索引掃描,這是帶來的必然是讀次數(shù)過多。我們期望看到的是seek或鍵查找。
6、怎么看SQL語句執(zhí)行的計劃很有講究,初學者會過于關(guān)注里面顯示的開銷比例,而實際上這個有時會誤導(dǎo)。我在實際優(yōu)化過程中就被發(fā)現(xiàn),一個index scan的執(zhí)行項開銷只占25%,另一個鍵查找的開銷占50%,而鍵查找部分根本沒有可優(yōu)化的,SEEK謂詞就是ID=XXX這個建立在主鍵上的查找。而仔細分析可以看到,后者CPU開銷0.00015,I/O開銷0.0013。而前者呢,CPU開銷1.4xxxx,I/O開銷也遠大于后者。因此,優(yōu)化重點應(yīng)該放在前者。
7、如何優(yōu)化單個部分,一個復(fù)雜的SQL語句,SQL SERVER會很聰明地重組WHERE后的語句,試圖匹配索引。選中帶優(yōu)化的步驟,選擇旁邊的‘屬性”,再選擇其中的“謂詞”,將其中部分復(fù)制下來,這部分就是分解后的WHERE 語句,然后在查詢界面中select * from 表 where 剛才復(fù)制下來的“謂詞”。這個就是需要優(yōu)化的部分,既然已經(jīng)走到這一步了,大部分人應(yīng)該能手動建立索引了,因為這里的WHERE語句比之前的肯定簡單不少。(在我項目中原始SELECT語句的WHERE部分有10個條件組合,涉及6個字段,提取出來要優(yōu)化的部分就4個條件,涉及到3個字段。新的索引建立后,CPU占用率一下子就降低了,而且新建立的索引涉及的字段屬于不常UPDATE的部分,頻繁的讀寫操作不會影響UPDATE的效率)
8、以上就是優(yōu)化的思路,最后提一些優(yōu)化過程或是系統(tǒng)設(shè)計時中需要注意的問題。
A、盡量避免用select * from xxx where abc like '%xxx'類型的模糊查詢,因為%在前面的話是無法利用到索引,必然會引起全量SCAN操作。應(yīng)該找尋替代方式或用前置條件語句把like查找之前的行數(shù)減到最低。
B、盡量避免對大表數(shù)據(jù)進行select top n * from xxx where xxxx order by newid()的取隨機記錄的操作。newid()操作會讀全量數(shù)據(jù)后再排序。也會占用大量CPU和讀操作??梢钥紤]用RAND()函數(shù)來實現(xiàn),這方面我還在研究中,對于整表操作比較好弄,比如id>=(select max(id) from table)*rand()。但如果取局部數(shù)據(jù)的隨機記錄還需要思量。
C、在SQL Server Profiler記錄中會看到Audit Logout會占用大量CPU和讀寫等操作。查了一些資料稱是某個鏈接在某次連接過程中執(zhí)行SQL語句產(chǎn)生的總數(shù),不用過于擔心??聪聛淼拇_似乎這樣,很多Audit Logout的CPU和IO消耗量和之前優(yōu)化的語句基本一致。所以在第5點我提的SQL語句用textdata is not null條件把Audit Logout給隱去。
D、兩個不同字段OR語句會導(dǎo)致全表掃描。例如 where m=1 or n=1。如果建立一個索引是m和n,同樣會引起scan,解決方法是給m和n分別建立索引。測試12萬條數(shù)據(jù)的表,索引建立錯誤的情況下IO開銷高達 10.xxx,分別建立索引后,全部變成0.003,這個反差是非常巨大的。雖然會引起INSERT操作的性能問題,但畢竟大部分瓶頸在SELECT的讀操作上。
E、索引查找(Index Seek)和索引掃描(Index Scan),我們需要的是前者,而引起后者的原因通常是某個索引里的字段多余要查找的,例如索引建立在A和B兩個字段,而我們只要查找A,則會導(dǎo)致 INDEX SCAN。建議針對單獨的A建立索引,以形成索引查找。
F、對于小表不建議建立索引,特別是幾百的數(shù)據(jù)量,只有上千上萬級別的數(shù)據(jù)建立索引才有效果。
數(shù)據(jù)庫優(yōu)化是很深的學問,在數(shù)據(jù)庫設(shè)計時就應(yīng)該注意,特別是最后提到的A、B兩點,盡可能在設(shè)計初期避免。
相關(guān)文章
SQL Server降權(quán)運行 SQL Server 2000以GUESTS權(quán)限運行設(shè)置方法
由于sql注入問題比較常見,很多黑客都是通過sqlserver數(shù)據(jù)庫漏洞直接獲取系統(tǒng)權(quán)限,所以sqlserver的安全設(shè)置尤為重要,簡單簡單分享下sqlserver低權(quán)限運行方法2014-07-07使用sqlplus創(chuàng)建DDL和DML操作方法
這篇文章主要介紹了使用sqlplus創(chuàng)建DDL和DML操作方法,需要的朋友可以參考下2018-04-04