<ruby id="rxdll"></ruby><strike id="rxdll"></strike>

    <rp id="rxdll"></rp>
      <del id="rxdll"><meter id="rxdll"></meter></del>
      <pre id="rxdll"><font id="rxdll"></font></pre>
        <pre id="rxdll"></pre>
      <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

      <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
      <i id="rxdll"><dfn id="rxdll"></dfn></i>
      <font id="rxdll"><meter id="rxdll"></meter></font>

        <mark id="rxdll"><dfn id="rxdll"></dfn></mark>
        • 軟件測試技術
        • 軟件測試博客
        • 軟件測試視頻
        • 開源軟件測試技術
        • 軟件測試論壇
        • 軟件測試沙龍
        • 軟件測試資料下載
        • 軟件測試雜志
        • 軟件測試人才招聘
          暫時沒有公告

        字號: | 推薦給好友 上一篇 | 下一篇

        寫出高性能SQL語句的十三條法則

        發布: 2011-2-21 10:03 | 作者: 不祥 | 來源: 領測軟件測試網采編 | 查看: 181次 | 進入軟件測試論壇討論

        領測軟件測試網

                寫出高性能SQL語句的十三條法則   軟件測試

          1、首先要搞明白什么叫執行計劃?

          執行計劃是數據庫根據SQL語句和相關表的統計信息作出的一個查詢方案,這個方案是由查詢優化器自動分析產生的,比如一條SQL語句如果用來從一個10萬條記錄的表中查1條記錄,那查詢優化器會選擇“索引查找”方式,如果該表進行了歸檔,當前只剩下5000條記錄了,那查詢優化器就會改變方案,采用“全表掃描”方式。

          可見,執行計劃并不是固定的,它是“個性化的”。產生一個正確的“執行計劃”有兩點很重要:

          (1)SQL語句是否清晰地告訴查詢優化器它想干什么?

          (2)查詢優化器得到的數據庫統計信息是否是最新的、正確的?

          2、統一SQL語句的寫法

          對于以下兩句SQL語句,程序員認為是相同的,數據庫查詢優化器認為是不同的。

          select * from dual

          select * From dual

          其實就是大小寫不同,查詢分析器就認為是兩句不同的SQL語句,必須進行兩次解析。生成2個執行計劃。所以作為程序員,應該保證相同的查詢語句在任何地方都一致,多一個空格都不行!

          3、不要把SQL語句寫得太復雜

          我經?吹,從數據庫中捕捉到的一條SQL語句打印出來有2張A4紙這么長。一般來說這么復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者,結果他說時間太長,他一時也看不懂了?上攵,連原作者都有可能看糊涂的SQL語句,數據庫也一樣會看糊涂。

          一般,將一個Select語句的結果作為子集,然后從該子集中再進行查詢,這種一層嵌套語句還是比較常見的,但是根據經驗,超過3層嵌套,查詢優化器就很容易給出錯誤的執行計劃。因為它被繞暈了。像這種類似人工智能的東西,終究比人的分辨力要差些,如果人都看暈了,我可以保證數據庫也會暈的。

          另外,執行計劃是可以被重用的,越簡單的SQL語句被重用的可能性越高。而復雜的SQL語句只要有一個字符發生變化就必須重新解析,然后再把這一大堆垃圾塞在內存里?上攵,數據庫的效率會何等低下。

          4、使用“臨時表”暫存中間結果

          簡化SQL語句的重要方法就是采用臨時表暫存中間結果,但是,臨時表的好處遠遠不止這些,將臨時結果暫存在臨時表,后面的查詢就在tempdb中了,這可以避免程序中多次掃描主表,也大大減少了程序執行中“共享鎖”阻塞“更新鎖”,減少了阻塞,提高了并發性能。

          5、OLTP系統SQL語句必須采用綁定變量

          select * from orderheader where changetime > ‘2010-10-20 00:00:01’

          select * from orderheader where changetime > ‘2010-09-22 00:00:01’

          以上兩句語句,查詢優化器認為是不同的SQL語句,需要解析兩次。如果采用綁定變量

          select * from orderheader where changetime > @chgtime

          @chgtime變量可以傳入任何值,這樣大量的類似查詢可以重用該執行計劃了,這可以大大降低數據庫解析SQL語句的負擔。一次解析,多次重用,是提高數據庫效率的原則。

          6、綁定變量窺測

          事物都存在兩面性,綁定變量對大多數OLTP處理是適用的,但是也有例外。比如在where條件中的字段是“傾斜字段”的時候。

          “傾斜字段”指該列中的絕大多數的值都是相同的,比如一張人口調查表,其中“民族”這列,90%以上都是漢族。那么如果一個SQL語句要查詢30歲的漢族人口有多少,那“民族”這列必然要被放在where條件中。這個時候如果采用綁定變量@nation會存在很大問題。

          試想如果@nation傳入的第一個值是“漢族”,那整個執行計劃必然會選擇表掃描。然后,第二個值傳入的是“布依族”,按理說“布依族”占的比例可能只有萬分之一,應該采用索引查找。但是,由于重用了第一次解析的“漢族”的那個執行計劃,那么第二次也將采用表掃描方式。這個問題就是著名的“綁定變量窺測”,建議對于“傾斜字段”不要采用綁定變量。

          7、只在必要的情況下才使用begin tran

          SQL Server中一句SQL語句默認就是一個事務,在該語句執行完成后也是默認commit的。其實,這就是begin tran的一個最小化的形式,好比在每句語句開頭隱含了一個begin tran,結束時隱含了一個commit。

          有些情況下,我們需要顯式聲明begin tran,比如做“插、刪、改”操作需要同時修改幾個表,要求要么幾個表都修改成功,要么都不成功。begin tran 可以起到這樣的作用,它可以把若干SQL語句套在一起執行,最后再一起commit。好處是保證了數據的一致性,但任何事情都不是完美無缺的。Begin tran付出的代價是在提交之前,所有SQL語句鎖住的資源都不能釋放,直到commit掉。

          可見,如果Begin tran套住的SQL語句太多,那數據庫的性能就糟糕了。在該大事務提交之前,必然會阻塞別的語句,造成block很多。

          Begin tran使用的原則是,在保證數據一致性的前提下,begin tran 套住的SQL語句越少越好!有些情況下可以采用觸發器同步數據,不一定要用begin tran。

        延伸閱讀

        文章來源于領測軟件測試網 http://www.k11sc111.com/

        21/212>

        關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
        版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
        北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備2023014753號-2
        技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

        軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

        国产女主播精品_国产片婬乱18一级毛片视频_国产午夜激无码av毛片不卡_国产精品欧美久久久天天影院
          <ruby id="rxdll"></ruby><strike id="rxdll"></strike>

          <rp id="rxdll"></rp>
            <del id="rxdll"><meter id="rxdll"></meter></del>
            <pre id="rxdll"><font id="rxdll"></font></pre>
              <pre id="rxdll"></pre>
            <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

            <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
            <i id="rxdll"><dfn id="rxdll"></dfn></i>
            <font id="rxdll"><meter id="rxdll"></meter></font>

              <mark id="rxdll"><dfn id="rxdll"></dfn></mark>