<output id="os3gq"><ruby id="os3gq"></ruby></output>

    1. <mark id="os3gq"></mark>
    2. 數據庫優化經驗分享-仇國平
      Access軟件網QQ交流學習群(群號碼198465573),歡迎您的加入!
      首頁 >技術文章> ADP及SQL SERVER


      數據庫優化經驗分享

      發表時間:2013/1/12 9:31:09 評論(1) 瀏覽(4960)  評論 | 加入收藏 | 復制
         
      摘 要:數據庫運行速度直接影響到你系統的認可度,要想數據庫能提高反應速度,就應該對數據庫進行優化。
      正 文:
      數據庫優化的目標無非是避免磁盤I/O瓶頸、減少CPU利用率和減少資源競爭。
      1、 在業務密集的SQL當中盡量不采用IN操作符
      2、  不使用not in 因為它不能應用表的索引。用not exists 或(外連接+判斷為空)代替
      3、  不使用<>,因為用它只會產生全表掃描。(a<>0改為a>0 or a<0)
      4、  不使用 is null 或 is not null 判斷字段是否為空一般不用到索引。(a is not null 改為a>0)
      5、  用a>=3代替a>2,因為a>2時,會先找出a為2的記錄索引再進行比較,而a>=3時,會直接找到a=3的索記錄引再進行比較。
      6、  盡量不使用like %005%(比如前面的%確定在{A,B}內,用A005% or B005%代替%005%)
      7、  union在進行表鏈接后會篩選掉重復的記錄。因此會用到排序運算。(若確定沒有重復記錄的用union all 代替union)
      8、  where 條件順序的影響。(如 select * from T where a=’abc’ and b=1 若a=”abc”在數據庫中的記錄比b=1在數據庫中的記錄多,則把b=1放在前面)
      9、  盡量避免以下情況:
      采用函數處理的字段不能利用索引
      進行了顯示或隱式運算的字段不能進行索引(把a-5=b 改為a=b+5)
      條件內包括多個本表字段不能進行索引
      10、合理使用索引,使用索引的原則:
      在經常進行連接,但是沒有指定為外鍵的列上建立索引,而不經常連接的字段則由優化器自動生成索引。
      在頻繁進行排序或分組(即進行group by或order by操作)的列上建立索引。
      在條件表達式中經常用到的不同值較多的列上建立檢索,在不同值少的列上不要建立索引。(比如在雇員表的“性別”列上只有“男”與“女”兩個不同值,因此就無必要建立索引。如果建立索引不但不會提高查詢效率,反而會嚴重降低更新速度。)
      如果待排序的列有多個,可以在這些列上建立復合索引(compound index)  
      當數據庫表更新大量數據后,刪除并重建索引可以提高查詢速度
      11、避免或簡化排序:為了避免不必要的排序,就要正確地增建索引,合理地合并數據庫表。如果排序不可避免,那么應當試圖簡化它,如縮小排序的列的范圍等
      12、消除對大型表行數據的順序存。涸谇短撞樵冎,對表的順序存取對查詢效率可能產生致命的影響。比如采用順序存取策略,一個嵌套3層的查詢,如果每層都查詢1000行,那么這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如,兩個表:學生表(學號、姓名、年齡……)和選課表(學號、課程號、成績)。如果兩個表要做連接,就要在“學號”這個連接字段上建立索引。
      還可以使用并集來避免順序存取。盡管在所有的檢查列上都有索引,但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作:
      Select * FROM orders Where (customer_num=104 AND order_num>1001) or order_num=1008
      雖然在customer_num和order_num上建有索引,但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合,所以應該改為如下語句:
      Select * FROM orders Where customer_num=104 AND order_num>1001
      UNION
      Select * FROM orders Where order_num=1008
      這樣就能利用索引路徑處理查詢。
      13、避免相關子查詢:一個列的標簽同時在主查詢和where子句中的查詢中出現,那么很可能當主查詢中的列值改變之后,子查詢必須重新查詢一次。查詢嵌套層次越多,效率越低,因此應當盡量避免子查詢。如果子查詢不可避免,那么要在子查詢中過濾掉盡可能多的行。
      14、避免困難的正規表達式(like):這種匹配特別耗費時間。例如:Select * FROM customer Where zipcode LIKE “98_ _ _” 即使在zipcode字段上建立了索引,在這種情況下也還是采用順序掃描的方式。如果把語句改為Select * FROM customer Where zipcode >“98000”,在執行查詢時就會利用索引來查詢,顯然會大大提高速度。
      15、使用臨時表加速查詢:把表的一個子集進行排序并創建臨時表,有時能加速查詢。它有助于避免多重排序操作,而且在其他方面還能簡化優化器的工作。例如:
      Select cust.name,rcvbles.balance,……other columns
      FROM cust,rcvbles
      Where cust.customer_id = rcvlbes.customer_id
      AND rcvblls.balance>0
      AND cust.postcode>“98000”
      orDER BY cust.name
      如果這個查詢要被執行多次而不止一次,可以把所有未付款的客戶找出來放在一個臨時文件中,并按客戶的名字進行排序:
      Select cust.name,rcvbles.balance,……other columns
      FROM cust,rcvbles
      Where cust.customer_id = rcvlbes.customer_id
      AND rcvblls.balance>0
      orDER BY cust.name
      INTO TEMP cust_with_balance
      然后以下面的方式在臨時表中查詢:
      Select * FROM cust_with_balance
      Where postcode>“98000”
      臨時表中的行要比主表中的行少,而且物理順序就是所要求的順序,減少了磁盤I/O,所以查詢工作量可以得到大幅減少。
      注意:臨時表創建后不會反映主表的修改。在主表中數據頻繁修改的情況下,注意不要丟失數據。
      16、用排序來取代非順序存。涸谶B接列上建立索引。(若非順序存取表的數據不經常改變,可以建立排序后的臨時表,再進行查詢。注意:臨時表不反映主表的改變。)
      17、有大量重復值、且經常有范圍查詢(between, >,< ,>=,< =)和order by、group by發生的列,可考慮建立群集索引
      18、經常同時存取多列,且每列都含有重復值可考慮建立組合索引
      19、組合索引要盡量使關鍵查詢形成索引覆蓋,其前導列一定是使用最頻繁的列
      20、注意where字句寫法,必須考慮語句順序,應該根據索引順序、范圍大小來確定條件子句的前后順序,盡可能的讓字段順序與索引順序相一致,范圍從大到小。
      21、盡量使用exists代替select count(1)來判斷是否存在記錄,count函數只有在統計表中所有行數時使用,而且count(1)比count(*)更有效率
       
      22、盡量使用“>=”,不要使用“>”
      23、盡可能的使用索引字段作為查詢條件,尤其是聚簇索引
      24、在使用索引字段作為條件時,如果該索引是聯合索引,那么必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引,否則該索引將不會被使用

      Access軟件網交流QQ群(群號:198465573)
       
       相關文章
      SQL Server 性能優化工具   【UMVsoft整理  2006/8/2】
      數據的優化和安全--如何加密/解密數據庫   【UMVSoft整理  2008/8/8】
      access開發平臺登陸界面美化加優化  【煮茶論道  2011/6/10】
      給我啟發的一篇文章:SQL SERVER優化建議  【愛好  2011/8/5】
      Sql優化查詢速度50個方法小結\SQL Server速度查詢優化...  【風行  2012/8/4】
      【Access小品】韜光養晦--線型材料開料優化示例  【煮江品茶  2012/8/19】
       
       訪客評論
      2015/3/11流水清
      這些經驗不知道要做多少案例才能總結出來啊,向前輩致敬!

      總記錄:1篇  頁次:1/1 9 1 :
       
       發表評論
      評論內容 (必填)

      常見問答
      技術分類
      相關資源
      文章搜索
      關于作者

      仇國平

      文章分類

      文章存檔

      友情鏈接
       
         
      湖北11选5