走在架構(gòu)師的大道上 Jack.Wang's home

          Java, C++, linux c, C#.net 技術(shù),軟件架構(gòu),領(lǐng)域建模,IT 項目管理 Dict.CN 在線詞典, 英語學(xué)習(xí), 在線翻譯

          BlogJava 首頁 新隨筆 聯(lián)系 聚合 管理
            195 Posts :: 3 Stories :: 728 Comments :: 0 Trackbacks
          附加一 SQL+PL/SQL 學(xué)習(xí)資料(很好的基礎(chǔ)文檔(個人珍藏版))/Files/Jack2007/Sqlplsql.pdf
                                                                                           /Files/Jack2007/sqlandplsql.pdf


          Oracle SQL的優(yōu)化規(guī)則:
          • 盡量少用IN操作符,基本上所有的IN操作符都可以用EXISTS代替
                  用IN寫出來的SQL的優(yōu)點是比較容易寫及清晰易懂,但是用IN的SQL性能總是比較低的,從ORACLE執(zhí)行的步驟來分析用IN的SQL與不用IN的SQL有以下區(qū)別:
                 ORACLE 試圖將其轉(zhuǎn)換成多個表的連接,如果轉(zhuǎn)換不成功則先執(zhí)行IN里面的子查詢,再查詢外層的表記錄,如果轉(zhuǎn)換成功則直接采用多個表的連接方式查詢。由此可見用 IN的SQL至少多了一個轉(zhuǎn)換的過程。一般的SQL都可以轉(zhuǎn)換成功,但對于含有分組統(tǒng)計等方面的SQL就不能轉(zhuǎn)換了。

                  Oracle在執(zhí)行IN子查詢時,首先執(zhí)行子查詢,將查詢結(jié)果放入臨時表再執(zhí)行主查詢。而EXIST則是首先檢查主查詢,然后運(yùn)行子查詢直到找到第一個匹配項。NOT EXISTS比NOT IN效率稍高。但具體在選擇IN或EXIST操作時,要根據(jù)主子表數(shù)據(jù)量大小來具體考慮。

                  推薦方案:在業(yè)務(wù)密集的SQL當(dāng)中盡量不采用IN操作符。
          不用NOT IN操作符,可以用NOT EXISTS或者外連接+替代
                  此操作是強(qiáng)列推薦不使用的,因為它不能應(yīng)用表的索引。

                  推薦方案:用NOT EXISTS 或(外連接+判斷為空)方案代替
          • 不用“<>”或者“!=”操作符。對不等于操作符的處理會造成全表掃描,可以用“<” or “>”代替
                  不等于操作符是永遠(yuǎn)不會用到索引的,因此對它的處理只會產(chǎn)生全表掃描。

                  推薦方案:用其它相同功能的操作運(yùn)算代替,如:
                  1)a<>0 改為 a>0 or a<0
                  2)a<>’’ 改為 a>’’
          • Where子句中出現(xiàn)IS NULL或者IS NOT NULL時,Oracle會停止使用索引而執(zhí)行全表掃描。可以考慮在設(shè)計表時,對索引列設(shè)置為NOT NULL。這樣就可以用其他操作來取代判斷NULL的操作
                  IS NULL 或IS NOT NULL操作(判斷字段是否為空)
                  判斷字段是否為空一般是不會應(yīng)用索引的,因為B樹索引是不索引空值的。

                  推薦方案:
                  用其它相同功能的操作運(yùn)算代替,如:
                  1)a is not null 改為 a>0 或a>’’等。
                  2)不允許字段為空,而用一個缺省值代替空值,如業(yè)擴(kuò)申請中狀態(tài)字段不允許為空,缺省為申請。
                 3) 建立位圖索引(有分區(qū)的表不能建,位圖索引比較難控制,如字段值太多索引會使性能下降,多人更新操作會增加數(shù)據(jù)塊鎖的現(xiàn)象)
          •  當(dāng)通配符“%”或者“_”作為查詢字符串的第一個字符時,索引不會被使用
          • 對于有連接的列“||”,最后一個連接列索引會無效。盡量避免連接,可以分開連接或者使用不作用在列上的函數(shù)替代。
          • 如果索引不是基于函數(shù)的,那么當(dāng)在Where子句中對索引列使用函數(shù)時,索引不再起作用。
          • Where子句中避免在索引列上使用計算,否則將導(dǎo)致索引失效而進(jìn)行全表掃描。
          • 對數(shù)據(jù)類型不同的列進(jìn)行比較時,會使索引失效。
          • > 及 < 操作符(大于或小于操作符)
                 大于或小于操作符一般情況下是不用調(diào)整的,因為它有索引就會采用索引查找,但有的情況下可以對它進(jìn)行優(yōu)化,如一個表有100萬記錄,一個數(shù)值型字段A, 30萬記錄的A=0,30萬記錄的A=1,39萬記錄的A=2,1萬記錄的A=3。那么執(zhí)行A>2與A>=3的效果就有很大的區(qū)別了,因為 A>2時ORACLE會先找出為2的記錄索引再進(jìn)行比較,而A>=3時ORACLE則直接找到=3的記錄索引。

                 推薦方案:用“>=”替代“>”。
          • UNION操作符
                 UNION在進(jìn)行表鏈接后會篩選掉重復(fù)的記錄,所以在表鏈接后會對所產(chǎn)生的結(jié)果集進(jìn)行排序運(yùn)算,刪除重復(fù)的記錄再返回結(jié)果。實際大部分應(yīng)用中是不會產(chǎn)生重復(fù)的記錄,最常見的是過程表與歷史表UNION。如:

              select * from gc_dfys
              union
              select * from ls_jg_dfys

              這個SQL在運(yùn)行時先取出兩個表的結(jié)果,再用排序空間進(jìn)行排序刪除重復(fù)的記錄,最后返回結(jié)果集,如果表數(shù)據(jù)量大的話可能會導(dǎo)致用磁盤進(jìn)行排序。

              推薦方案:采用UNION ALL操作符替代UNION,因為UNION ALL操作只是簡單的將兩個結(jié)果合并后就返回。

              select * from gc_dfys
              union all
              select * from ls_jg_dfys
          • LIKE操作符
                  LIKE 操作符可以應(yīng)用通配符查詢,里面的通配符組合可能達(dá)到幾乎是任意的查詢,但是如果用得不好則會產(chǎn)生性能上的問題,如LIKE ‘%5400%’ 這種查詢不會引用索引,而LIKE ‘X5400%’則會引用范圍索引。一個實際例子:用YW_YHJBQK表中營業(yè)編號后面的戶標(biāo)識號可來查詢營業(yè)編號 YY_BH LIKE ‘%5400%’ 這個條件會產(chǎn)生全表掃描,如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 則會利用YY_BH的索引進(jìn)行兩個范圍的查詢,性能肯定大大提高。
          • SQL書寫的影響(共享SQL語句可以提高操作效率)
              同一功能同一性能不同寫法SQL的影響

              如一個SQL在A程序員寫的為
              Select * from zl_yhjbqk

              B程序員寫的為
              Select * from dlyx.zl_yhjbqk(帶表所有者的前綴)

              C程序員寫的為
              Select * from DLYX.ZLYHJBQK(大寫表名)

              D程序員寫的為
              Select *  from DLYX.ZLYHJBQK(中間多了空格)

               以上四個SQL在ORACLE分析整理之后產(chǎn)生的結(jié)果及執(zhí)行的時間是一樣的,但是從ORACLE共享內(nèi)存SGA的原理,可以得出ORACLE對每個SQL 都會對其進(jìn)行一次分析,并且占用共享內(nèi)存,如果將SQL的字符串及格式寫得完全相同則ORACLE只會分析一次,共享內(nèi)存也只會留下一次的分析結(jié)果,這不僅可以減少分析SQL的時間,而且可以減少共享內(nèi)存重復(fù)的信息,ORACLE也可以準(zhǔn)確統(tǒng)計SQL的執(zhí)行頻率。

              推薦方案:不同區(qū)域出現(xiàn)的相同的Sql語句,要保證查詢字符完全相同,以利用SGA共享池,防止相同的Sql語句被多次分析。
          • WHERE后面的條件順序影響
                 Oracle從下到上處理Where子句中多個查詢條件,所以表連接語句應(yīng)寫在其他Where條件前,可以過濾掉最大數(shù)量記錄的條件必須寫在Where子句的末尾。
                
                 WHERE子句后面的條件順序?qū)Υ髷?shù)據(jù)量表的查詢會產(chǎn)生直接的影響,如

              Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1

              Select * from zl_yhjbqk where xh_bz=1  and dy_dj = '1KV以下'

              以上兩個SQL中dy_dj(電壓等級)及xh_bz(銷戶標(biāo)志)兩個字段都沒進(jìn)行索引,所以執(zhí)行的時候都是全表掃描,第一條SQL的dy_dj = '1KV以下'條件在記錄集內(nèi)比率為99%,而xh_bz=1的比率只為0.5%,在進(jìn)行第一條SQL的時候99%條記錄都進(jìn)行dy_dj及xh_bz的比較,而在進(jìn)行第二條SQL的時候0.5%條記錄都進(jìn)行dy_dj及xh_bz的比較,以此可以得出第二條SQL的CPU占用率明顯比第一條低。
          • 查詢表順序的影響
                 Oracle從右到左處理From子句中的表名,所以在From子句中包含多個表的情況下,將記錄最少的表放在最后。(只在采用RBO優(yōu)化時有效)

                 在FROM后面的表中的列表順序會對SQL執(zhí)行性能影響,在沒有索引及ORACLE沒有對表進(jìn)行統(tǒng)計分析的情況下ORACLE會按表出現(xiàn)的順序進(jìn)行鏈接,由此因為表的順序不對會產(chǎn)生十分耗服務(wù)器資源的數(shù)據(jù)交叉。(注:如果對表進(jìn)行了統(tǒng)計分析, ORACLE會自動先進(jìn)小表的鏈接,再進(jìn)行大表的鏈接)。
          • Order By語句中的非索引列會降低性能,可以通過添加索引的方式處理。嚴(yán)格控制在Order By語句中使用表達(dá)式
          • 當(dāng)在Sql語句中連接多個表時,使用表的別名,并將之作為每列的前綴。這樣可以減少解析時間
          • 多利用內(nèi)部函數(shù)提高Sql效率
          •  SQL語句索引的利用
            • 對操作符的優(yōu)化(見前面)
            • 對條件字段的一些優(yōu)化
              • 采用函數(shù)處理的字段不能利用索引
                    如:
                  substr(hbs_bh,1,4)=’5400’,優(yōu)化處理:hbs_bh like ‘5400%’

                  trunc(sk_rq)=trunc(sysdate), 優(yōu)化處理:sk_rq>=trunc(sysdate) and sk_rq<trunc(sysdate+1)
              • 進(jìn)行了顯式或隱式的運(yùn)算的字段不能進(jìn)行索引
                    如:

                  ss_df+20>50,優(yōu)化處理:ss_df>30

                  ‘X’||hbs_bh>’X5400021452’,優(yōu)化處理:hbs_bh>’5400021542’

                  sk_rq+5=sysdate,優(yōu)化處理:sk_rq=sysdate-5

                  hbs_bh=5401002554,優(yōu)化處理:hbs_bh=’ 5401002554’,注:此條件對hbs_bh 進(jìn)行隱式的to_number轉(zhuǎn)換,因為hbs_bh字段是字符型。
              • 條件內(nèi)包括了多個本表的字段運(yùn)算時不能進(jìn)行索引
                    ys_df>cx_df,無法進(jìn)行優(yōu)化

                    qc_bh||kh_bh=’5400250000’,優(yōu)化處理:qc_bh=’5400’ and kh_bh=’250000’


              可能引起全表掃描的操作
          • 在索引列上使用NOT或者“<>”
          • 對索引列使用函數(shù)或者計算
          • NOT IN操作
          • 通配符位于查詢字符串的第一個字符
          • IS NULL或者IS NOT NULL
          • 多列索引,但它的第一個列并沒有被Where子句引用

                 ORACLE在SQL執(zhí)行分析方面已經(jīng)比較成熟,如果分析執(zhí)行的路徑不對首先應(yīng)在數(shù)據(jù)庫結(jié)構(gòu)(主要是索引)、服務(wù)器當(dāng)前性能(共享內(nèi)存、磁盤文件碎片)、數(shù)據(jù)庫對象(表、索引)統(tǒng)計信息是否正確這幾方面分析。


          轉(zhuǎn)載聲明:http://aofengblog.blog.163.com/blog/static/631702120083222117768/



          本博客為學(xué)習(xí)交流用,凡未注明引用的均為本人作品,轉(zhuǎn)載請注明出處,如有版權(quán)問題請及時通知。由于博客時間倉促,錯誤之處敬請諒解,有任何意見可給我留言,愿共同學(xué)習(xí)進(jìn)步。
          posted on 2008-06-30 19:01 Jack.Wang 閱讀(12955) 評論(8)  編輯  收藏 所屬分類: 開發(fā)技術(shù)

          Feedback

          # re: Oracle SQL 優(yōu)化 2008-06-30 21:45 隔葉黃鶯
          這個很實用,但是對于一般的開發(fā)人員寫 SQL 語句最初都是為了意義上的好理解,只有發(fā)現(xiàn)性能很明顯不足時才有可能介入專職DBA來檢查。

          開發(fā)人員掌握這些基本的 Oralce SQL 優(yōu)化是很有必要的,OK,我也從原文轉(zhuǎn)載一下。  回復(fù)  更多評論
            

          # re: Oracle SQL 優(yōu)化 2008-07-01 19:55 藍(lán)劍
          確實很實用!  回復(fù)  更多評論
            

          # re: Oracle SQL 優(yōu)化 2008-07-03 08:52 龐永慶
          你好,我們是出版公司,公司現(xiàn)在正先出版一本SQL優(yōu)化的書,如果有興趣可以和我聯(lián)系。
          books_522008@yahoo.com.cn
          MSN:pyq_19852008@hotmail.com
          QQ:878 298 915 注明SQL  回復(fù)  更多評論
            

          # 關(guān)于”WHERE后面的條件順序影響“這一段,是不是有問題? 2010-07-14 14:36 yangzhj
          原文:
          WHERE后面的條件順序影響
          Oracle從下到上處理Where子句中多個查詢條件,所以表連接語句應(yīng)寫在其他Where條件前,可以過濾掉最大數(shù)量記錄的條件必須寫在Where子句的末尾。
          WHERE子句后面的條件順序?qū)Υ髷?shù)據(jù)量表的查詢會產(chǎn)生直接的影響,如
          Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
          Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
          以上兩個SQL中dy_dj(電壓等級)及xh_bz(銷戶標(biāo)志)兩個字段都沒進(jìn)行索引,所以執(zhí)行的時候都是全表掃描,第一條SQL的dy_dj = '1KV以下'條件在記錄集內(nèi)比率為99%,而xh_bz=1的比率只為0.5%,在進(jìn)行第一條SQL的時候99%條記錄都進(jìn)行dy_dj及xh_bz的比較,而在進(jìn)行第二條SQL的時候0.5%條記錄都進(jìn)行dy_dj及xh_bz的比較,以此可以得出第二條SQL的CPU占用率明顯比第一條低。

          “可以過濾掉最大數(shù)量記錄的條件必須寫在Where子句的末尾”
          而作者舉的例子中,顯然第一條SQL更符合這個條件,
          但得出的結(jié)果是:“以此可以得出第二條SQL的CPU占用率明顯比第一條低。

            回復(fù)  更多評論
            

          # re: Oracle SQL 優(yōu)化[未登錄] 2011-08-09 11:43 1
          @yangzhj
          做個簡單的計算就可以肯定這有問題

          假設(shè)表A有n條記錄,非索引謂詞a,b,c.過濾率分別為1%, 30% ,90%,
          按照樓主的計算方式則:
          1. 先用a條件過來,則為全表掃描 io簡單認(rèn)為: n
          2. 再用b: 則為 0.01n
          3. 在用c: 則為 0.01*0.3n

          最后io為 n*0.01n*0.3n=O(n^3)

          如果不考慮條件順序,全表掃描然后對3個條件做一次匹配 則為O(n)

          很明顯下面的方式效率高很多。

          不過我where 條件順序還是有影響的,就算全表掃描然后對3個條件做一次匹配因為有bool表達(dá)式短路效益也可以減少比較次數(shù)。

            回復(fù)  更多評論
            

          # re: Oracle SQL 優(yōu)化 2012-11-21 17:44 guf
          不錯不錯,肯定是筆誤,寫錯了。  回復(fù)  更多評論
            

          # re: Oracle SQL 優(yōu)化 2013-08-17 09:33 kestrelley
          # re: Oracle SQL 優(yōu)化[未登錄] 2011-08-09 11:43 1
          @yangzhj
          做個簡單的計算就可以肯定這有問題
          ...
          ————
          某人思考邏輯有誤?
          ----
          假設(shè)10000個記錄,則按樓主:
          a條件作用^10000,則結(jié)果100 (=10000* 0.01)
          b條件作用^100,則結(jié)果30(=100*0.3)
          c條件作用^30,則結(jié)果27(=30* 0.9)
          合計計算量: a*10000 + b*100 + c*30,并非 O(n^3)

          而顯然一次全表掃描,計算量=(a+b+c)*10000
          ————
          哪個快呢?

            回復(fù)  更多評論
            

          # re: Oracle SQL 優(yōu)化 2013-11-18 19:18 yimeng
          @yangzhj
          確實第一條 性能更優(yōu)  回復(fù)  更多評論
            

          主站蜘蛛池模板: 婺源县| 邹平县| 余江县| 建德市| 白玉县| 南丰县| 苏州市| 麻阳| 建水县| 云阳县| 灌南县| 西平县| 客服| 安岳县| 阳曲县| 滨海县| 大冶市| 那坡县| 全州县| 安岳县| 余干县| 昌邑市| 辽源市| 怀远县| 林西县| 唐山市| 龙里县| 宜都市| 乌拉特后旗| 枣阳市| 康平县| 白朗县| 明溪县| 侯马市| 札达县| 安徽省| 江口县| 凌源市| 惠安县| 天峻县| 嘉荫县|