|
|
作者:々莫moke克々
2006-11-13 00:01 回覆此發言
|
|
16、用Profiler來跟蹤查詢,得到查詢所需的時間,找出SQL的問題所在;用索引優化器優化索引 17、注意UNion和UNion all 的區別。UNION all好 18、注意使用DISTINCT,在沒有必要時不要用,它同UNION一樣會使查詢變慢。重複的記錄在查詢裏是沒有問題的 19、查詢時不要返回不需要的行、列 20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來限制查詢消耗的資源。當評估查詢消耗的資源超出限制時,服務器自動取消查詢,在查詢之前就扼殺掉。SET LOCKTIME設置鎖的時間 21、用select top 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行 22、在SQL2000以前,一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'",因爲他們不走索引全是表掃描。也不要在WHere字句中的列名加函數,如Convert,substring等,如果必須用函數的時候,創建計算列再創建索引來替代.還可以變通寫法:WHERE SUBSTRING(firstname,1,1) = 'm'改爲WHERE firstname like 'm%'(索引掃描),一定要將函數和列名分開。並且索引不能建得太多和太大。NOT IN會多次掃描表,使用EXISTS、NOT EXISTS ,IN , LEFT OUTER JOIN 來替代,特別是左連接,而Exists比IN更快,最慢的是NOT操作.如果列的值含有空,以前它的索引不起作用,現在2000的優化器能夠處理了。相同的是IS NULL,"NOT", "NOT EXISTS", "NOT IN"能優化她,而"<>"等還是不能優化,用不到索引。 23、使用Query Analyzer,查看SQL語句的查詢計劃和評估分析是否是優化的SQL。一般的20%的代碼佔據了80%的資源,我們優化的重點是這些慢的地方。 24、如果使用了IN或者OR等時發現查詢沒有走索引,使用顯示申明指定索引: SELECT * FROM PersonMember (INDEX = IX_Title) WHERE processid IN ('男','女') 25、將需要查詢的結果預先計算好放在表中,查詢的時候再SELECT。這在SQL7.0以前是最重要的手段。例如醫院的住院費計算。 26、MIN() 和 MAX()能使用到合適的索引。 27、數據庫有一個原則是代碼離數據越近越好,所以優先選擇Default,依次爲Rules,Triggers, Constraint(約束如外健主健CheckUNIQUE……,數據類型的最大長度等等都是約束),Procedure.這樣不僅維護工作小,編寫程序質量高,並且執行的速度快。 28、如果要插入大的二進制值到Image列,使用存儲過程,千萬不要用內嵌INsert來插入(不知JAVA是否)。因爲這樣應用程序首先將二進制值轉換成字符串(尺寸是它的兩倍),服務器受到字符後又將他轉換成二進制值.存儲過程就沒有這些動作: 方法:Create procedure p_insert as insert into table(Fimage) values (@image), 在前臺調用這個存儲過程傳入二進制參數,這樣處理速度明顯改善。 29、Between在某些時候比IN速度更快,Between能夠更快地根據索引找到範圍。用查詢優化器可見到差別。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一樣的。由於in會在比較多次,所以有時會慢些。 30、在必要是對全局或者局部臨時表創建索引,有時能夠提高速度,但不是一定會這樣,因爲索引也耗費大量的資源。他的創建同是實際表一樣。 31、不要建沒有作用的事物例如產生報表時,浪費資源。只有在必要使用事物時使用它。 32、用OR的字句可以分解成多個查詢,並且通過UNION 連接多個查詢。他們的速度只同是否使用索引有關,如果查詢需要用到聯合索引,用UNION all執行的效率更高.多個OR的字句沒有用到索引,改寫成UNION的形式再試圖與索引匹配。一個關鍵的問題是否用到索引。 33、儘量少用視圖,它的效率低。對視圖操作比直接對錶操作慢,可以用stored procedure來代替她。特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度。我們看視圖的本質:它是存放在服務器上的被優化好了的已經產生了查詢規劃的SQL。對單個表檢索數據時,不要使用指向多個表的視圖,直接從表檢索或者僅僅包含這個表的視圖上讀,否則增加了不必要的開銷,查詢受到干擾.爲了加快視圖的查詢,MsSQL增加了視圖索引的功能。 |
34、沒有必要時不要用DISTINCT和ORDER BY,這些動作可以改在客戶端執行。它們增加了額外的開銷。這同UNION 和UNION ALL一樣的道理。 select top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345', 'JCNAD00333138','JCNAD00303570','JCNAD00303569', 'JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933', 'JCNAD00254567','JCNAD00254585','JCNAD00254608', 'JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618', 'JCNAD00279196','JCNAD00268613') order by postdate desc 35、在IN後面值的列表中,將出現最頻繁的值放在最前面,出現得最少的放在最後面,減少判斷的次數。 36、當用SELECT INTO時,它會鎖住系統表(sysobjects,sysindexes等等),阻塞其他的連接的存取。創建臨時表時用顯示申明語句,而不是select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一個連接中SELECT * from sysobjects可以看到 SELECT INTO 會鎖住系統表,Create table 也會鎖系統表(不管是臨時表還是系統表)。所以千萬不要在事物內使用它!!!這樣的話如果是經常要用的臨時表請使用實表,或者臨時表變量。 37、一般在GROUP BY 個HAVING字句之前就能剔除多餘的行,所以儘量不要用它們來做剔除行的工作。他們的執行順序應該如下最優:select 的Where字句選擇所有合適的行,Group By用來分組個統計行,Having字句用來剔除多餘的分組。這樣Group By 個Having的開銷小,查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算,只是分組,那麼用Distinct更快 38、一次更新多條記錄比分多次更新每次一條快,就是說批處理好 39、少用臨時表,儘量用結果集和Table類性的變量來代替它,Table 類型的變量比臨時表好 40、在SQL2000下,計算字段是可以索引的,需要滿足的條件如下: a、計算字段的表達是確定的 b、不能用在TEXT,Ntext,Image數據類型 c、必須配製如下選項 ANSI_NULLS = ON, ANSI_PADDINGS = ON, ……. 41、儘量將數據的處理工作放在服務器上,減少網絡的開銷,如使用存儲過程。存儲過程是編譯好、優化過、並且被組織到一個執行規劃裏、且存儲在數據庫中的SQL語句,是控制流語言的集合,速度當然快。反覆執行的動態SQL,可以使用臨時存儲過程,該過程(臨時表)被放在Tempdb中。以前由於SQL SERVER對複雜的數學計算不支持,所以不得不將這個工作放在其他的層上而增加網絡的開銷。SQL2000支持UDFs,現在支持複雜的數學計算,函數的返回值不要太大,這樣的開銷很大。用戶自定義函數象光標一樣執行的消耗大量的資源,如果返回大的結果採用存儲過程 42、不要在一句話裏再三的使用相同的函數,浪費資源,將結果放在變量裏再調用更快 43、SELECT COUNT(*)的效率教低,儘量變通他的寫法,而EXISTS快.同時請注意區別: select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!! 44、當服務器的內存夠多時,配製線程數量 = 最大連接數+5,這樣能發揮最大的效率;否則使用 配製線程數量<最大連接數啓用SQL SERVER的線程池來解決,如果還是數量 = 最大連接數+5,嚴重的損害服務器的性能。 45、按照一定的次序來訪問你的表。如果你先鎖住表A,再鎖住表B,那麼在所有的存儲過程中都要按照這個順序來鎖定它們。如果你(不經意的)某個存儲過程中先鎖定表B,再鎖定表A,這可能就會導致一個死鎖。如果鎖定順序沒有被預先詳細的設計好,死鎖很難被發現 |
|