SQL編寫規(guī)范和優(yōu)化講稿

SQL編寫規(guī)范和優(yōu)化

SQL編寫規(guī)范--1原則定義

1、要求代碼行清晰、整齊，具有一定的可觀賞性；

2、代碼編寫要充分考慮執(zhí)行速度最優(yōu)的原則；

3、代碼行整體層次分明、結(jié)構(gòu)化強(qiáng)；

4、代碼中應(yīng)有必要的注釋以增強(qiáng)代碼的可讀性；

5、規(guī)范要求非強(qiáng)制性約束代碼開發(fā)人員的代碼編寫行為，在實(shí)際應(yīng)用中在不違反常規(guī)要求的前提下允許存在可理解的偏差。SQL編寫規(guī)范--2大小寫規(guī)則

1、所有的SQL語句中的保留字均采用全部大寫，不要使用縮寫；表別名也要大寫；如ALLASCASECREATEDATABASEDELETEFROMININSERTJOINLEFTNONOTNULLOUTSELECTTABLETITLEUPDATEVIEWWHERE等。

2、表名、視圖名、宏和存儲過程名：全部小寫；SQL編寫規(guī)范--2大小寫規(guī)則

3、字段名：每個(gè)單詞的首字母大寫，其余部分小寫，如party_id,loc_id,prod_inst_id,Acct_Id,Type_Id等；使用如下語句獲得字段列表:SQL編寫規(guī)范--3縮進(jìn)和換行

整個(gè)的SQL語句最好按照子句進(jìn)行分行編寫，SELECT/FROM/WHERE/UPDATE/INSERT等每個(gè)關(guān)鍵字都要另起一行。如：SQL編寫規(guī)范--3縮進(jìn)和換行SQL編寫規(guī)范--3縮進(jìn)和換行

1、同一級別的子句間要對齊

2、逗號放在每行的開頭

3、分號放在SQL語句的最后，單獨(dú)占一行

4、每行寬度不超過120字符(每個(gè)字符為8個(gè)點(diǎn)陣寬)，超過行寬的代碼可折行與上行對齊編排；

5、每個(gè)字段后面使用字段標(biāo)題作為注釋

6、使用給出的語句獲得字段列表和字段標(biāo)題(借助UltraEdit列模式快速編輯)SQL編寫規(guī)范--3縮進(jìn)和換行下面的編寫方式不是好的形式：在所有需要縮進(jìn)的地方，每次縮進(jìn)4格；在以下情況下需要縮進(jìn)：

1、不同層次的SQL語句之間

2、SELECTINSERT等關(guān)鍵字之后的字段列表和關(guān)鍵字之間SQL編寫規(guī)范--4別名

SQL語句別名的命名，分層命名，從第一層次至第四層次，分別用P、S、U、D（都是大寫字母）表示，取意為Part,Segment,Unit,Detail。對于同一層次的多個(gè)子句，在字母后加1、2、3、4……區(qū)分。SQL編寫規(guī)范--4別名

如下圖所示：SQL編寫規(guī)范--5運(yùn)算符前后間間隔要求算術(shù)運(yùn)算符、、邏輯運(yùn)算符符的前后至少少要保留一個(gè)個(gè)空格，如下下圖所示：SQL編寫規(guī)范--6變量引用1、在SQL語句中引用變變量時(shí)，要在在變量名兩端端加花括號2、對日期變量量的引用要在在單引號內(nèi)，，如'${MYDATE}'SQL編寫規(guī)范--7注釋針對復(fù)雜的SQL語句，請盡量量增加相應(yīng)的的注釋說明，，以便自己和和其它同事事事后可以比較較容易的讀懂懂和修改。注釋中應(yīng)包含含以下內(nèi)容：：1、編寫人/編寫日期2、修改人/修改日期3、該腳本的編編寫目的與主主要內(nèi)容4、如果有特殊殊處理、特別別的技巧等內(nèi)內(nèi)容，一定要要在注釋中詳詳細(xì)說明SQL編寫規(guī)范--7注釋5、每一段SQL的前面必須要要有注釋，重重點(diǎn)說明該SQL的技術(shù)含義和和應(yīng)用含義、、選擇理由。。技術(shù)含義指指這段SQL在技術(shù)上這么么寫的原因、、好處，應(yīng)用用含義指這段段SQL從應(yīng)用的角度度將，是為了了達(dá)到一個(gè)什什么樣的目的的。如果有可可能，還需要要說明為什么么這么選擇，，而不選擇別別的方式的理理由。如果發(fā)發(fā)現(xiàn)了不足，，還可記錄不不足的原因和和建議的解決決辦法等。SQL編寫規(guī)范--8連接的使用對于內(nèi)連接和和外連接的使使用，要求該該使用外連接接的地方都已已經(jīng)使用了外外連接，不需需要外連接的的地方一定不不使用外連接接。表中的字段若若是從其它表表引用的，要要確保該字段段在被引用的的表中存在。。SQL編寫規(guī)范--8連接的使用要求所有的連連接都寫成JOIN的形式，如：：SQL編寫規(guī)范--8連接的使用而不要寫成：：SQL編寫規(guī)范--8連接的使用另外，為了保保證多表連接接的連接條件件穿透性，要要求在多表連連接的SQL書寫時(shí)將連接接條件有機(jī)的的閉環(huán)起來，，尤其是多表表PI相同，并用PI連接時(shí)。SQL編寫規(guī)范--8連接的使用例如：SQL編寫規(guī)范--8連接的使用即連接條件如如下所示：SQL優(yōu)化(teradata)SQL腳本優(yōu)化原則則要優(yōu)化腳本，，在深刻理解解業(yè)務(wù)邏輯的的基礎(chǔ)上，一一個(gè)重要的方方式是一段一一段的查看SQL的執(zhí)行計(jì)劃，，然后針對執(zhí)執(zhí)行計(jì)劃中不不合理、不優(yōu)優(yōu)化的地方對對SQL進(jìn)行優(yōu)化編寫寫，這項(xiàng)工作作需要實(shí)踐經(jīng)經(jīng)驗(yàn)，經(jīng)?？纯磮?zhí)行計(jì)劃會會有所幫助。。SQL優(yōu)化(teradata)SQL腳本優(yōu)化原則則表級優(yōu)化可以以參照以下以以下優(yōu)化原則則：(1)如果過濾性不不很強(qiáng)，又不不需要重分布布，對大表盡盡可能不要只只做一下過濾濾就進(jìn)一次SPOOL，最好是直接接與別的表JOIN，邊JOIN邊過濾了；(2)如果過濾性非非常強(qiáng)，可以以只做一下過過濾就進(jìn)一次次SPOOL；SQL優(yōu)化(teradata)SQL腳本優(yōu)化原則則(3)SPOOL空間盡量小原原則，即盡可可能使中間過過程中的SPOOL空間小一些，，這樣可以減減小I/O以及繼續(xù)關(guān)聯(lián)聯(lián)的代價(jià)；在在此原則下可可以引申出下下面幾個(gè)具體體原則：(3.1)在幾個(gè)表大小小差不多時(shí)，，過濾性條件件較強(qiáng)的先JOIN；(3.2)在大/大/小三個(gè)表內(nèi)聯(lián)聯(lián)時(shí)，避免先先把兩個(gè)大表表JOIN，除非過濾條條件非常強(qiáng)；；(3.3)在大/小/小三個(gè)表內(nèi)聯(lián)聯(lián)時(shí)，盡量先先把兩個(gè)小表表JOIN；(3.4)有時(shí)將看似沒沒必要的過濾濾條件加上，，在關(guān)聯(lián)表較較多時(shí)可能有有效的減小SPOOL；如表A、B、C、D的關(guān)聯(lián)字段均均為k，即A.k=B.kANDA.k=C.kANDA.k=D.k，而同時(shí)還有有條件substr(A.k,1,2)='01'，有時(shí)加上substr(B.k,1,2)='01'、substr(C.k,1,2)='01'、substr(D.k,1,2)='01‘會有好處；SQL優(yōu)化(teradata)SQL腳本優(yōu)化原則則(4)盡量避免大表表重分布；(5)當(dāng)大表與很小小的表(記錄數(shù)量級在在5位數(shù)以內(nèi))JOIN時(shí)，盡量讓小小表Duplicate；(6)如果必須有重重分布時(shí)，盡盡量使之靠后后；(7)盡量減少較大大的中間過程程中的SPOOL空間重分布的的次數(shù)；SQL優(yōu)化(teradata)SQL腳本優(yōu)化原則則(8)遇到productjoin時(shí)要小心一些些；(9)盡量減少對大大表的掃描次次數(shù)；(10)在拆SQL時(shí)也應(yīng)注意，，合起來雖然然可能大些，，但只掃描一一次大表，而而拆成多句后后就要多次掃掃描大表，可可能效率反降降；SQL優(yōu)化(oracle)基于索引的SQL語句優(yōu)化數(shù)據(jù)庫的優(yōu)化化方法有很多多種，在應(yīng)用用層來說，主主要是基于索索引的優(yōu)化。。難就難在如如何判斷哪些些索引是必要要的，哪些又又是不必要的的。判斷的最最終標(biāo)準(zhǔn)是看看這些索引是是否對我們的的數(shù)據(jù)庫性能能有所幫助。。具體到方法上上，就必須熟熟悉數(shù)據(jù)庫應(yīng)應(yīng)用程序中的的所有SQL語句，從中統(tǒng)統(tǒng)計(jì)出常用的的可能對性能能有影響的部部分SQL，分析、歸納納出作為Where條件子句的字字段及其組合合方式；在這這一基礎(chǔ)上可可以初步判斷斷出哪些表的的哪些字段應(yīng)應(yīng)該建立索引引。SQL優(yōu)化(oracle)基于索引的SQL語句優(yōu)化其次，必須熟熟悉應(yīng)用程序序。必須了解解哪些表是數(shù)數(shù)據(jù)操作頻繁繁的表；哪些些表經(jīng)常與其其他表進(jìn)行連連接；哪些表表中的數(shù)據(jù)量量可能很大；；對于數(shù)據(jù)量量大的表，其其中各個(gè)字段段的數(shù)據(jù)分布布情況如何；；等等。對于于滿足以上條條件的這些表表，必須重點(diǎn)點(diǎn)關(guān)注，因?yàn)闉樵谶@些表上上的索引，將將對SQL語句的性能產(chǎn)產(chǎn)生舉足輕重重的影響SQL優(yōu)化(oracle)基于索引的SQL語句優(yōu)化建立索引常用用的規(guī)則如下下：1、表的主鍵、、外鍵必須有有索引；2、數(shù)據(jù)量超過過300的表應(yīng)該有索索引；3、經(jīng)常與其他他表進(jìn)行連接接的表，在連連接字段上應(yīng)應(yīng)該建立索引引；4、經(jīng)常出現(xiàn)在在Where子句中的字段段，特別是大大表的字段，，應(yīng)該建立索索引；5、索引應(yīng)該建建在選擇性高高的字段上；；SQL優(yōu)化(oracle)基于索引的SQL語句優(yōu)化6、索引應(yīng)該建建在小字段上上，對于大的的文本字段甚甚至超長字段段，不要建索索引；7、復(fù)合索引的的建立需要進(jìn)進(jìn)行仔細(xì)分析析；盡量考慮慮用單字段索索引代替：A、正確選擇復(fù)復(fù)合索引中的的主列字段，，一般是選擇擇性較好的字字段；B、復(fù)合索引的的幾個(gè)字段是是否經(jīng)常同時(shí)時(shí)以AND方式出現(xiàn)在Where子句中？單字字段查詢是否否極少甚至沒沒有？如果是是，則可以建建立復(fù)合索引引；否則考慮慮單字段索引引；SQL優(yōu)化(oracle)基于索引的SQL語句優(yōu)化C、如果復(fù)合索索引中包含的的字段經(jīng)常單單獨(dú)出現(xiàn)在Where子句中，則分分解為多個(gè)單單字段索引；；D、如果復(fù)合索索引所包含的的字段超過3個(gè)，那么仔細(xì)細(xì)考慮其必要要性，考慮減減少復(fù)合的字字段；E、如果既有單單字段索引，，又有這幾個(gè)個(gè)字段上的復(fù)復(fù)合索引，一一般可以刪除除復(fù)合索引；；SQL優(yōu)化(oracle)基于索引的SQL語句優(yōu)化8、頻繁進(jìn)行數(shù)數(shù)據(jù)操作的表表，不要建立立太多的索引引；9、刪除無用的的索引，避免免對執(zhí)行計(jì)劃劃造成負(fù)面影影響；以上是一些普普遍的建立索索引時(shí)的判斷斷依據(jù)。一言言以蔽之，索索引的建立必必須慎重，對對每個(gè)索引的的必要性都應(yīng)應(yīng)該經(jīng)過仔細(xì)細(xì)分析，要有有建立的依據(jù)據(jù)。SQL優(yōu)化(oracle)基于索引的SQL語句優(yōu)化太多的索引與與不充分、不不正確的索引引對性能都毫毫無益處：在在表上建立的的每個(gè)索引都都會增加存儲儲開銷，索引引對于插入、、刪除、更新新操作也會增增加處理上的的開銷。另另外，過多的的復(fù)合索引，，在有單字段段索引的情況況下，一般都都是沒有存在在價(jià)值的；相相反，還會降降低數(shù)據(jù)增加加刪除時(shí)的性性能，特別是是對頻繁更新新的表來說，，負(fù)面影響更更大。SQL優(yōu)化(oracle)避免對列的的操作任何對列的的操作都可可能導(dǎo)致全全表掃描，，這里所謂謂的操作包包括數(shù)據(jù)庫庫函數(shù)、計(jì)計(jì)算表達(dá)式式等等，查查詢時(shí)要盡盡可能將操操作移至等等式的右邊邊，甚至去去掉函數(shù)。。例1：下列SQL條件語句中中的列都建建有恰當(dāng)?shù)牡乃饕?0萬行數(shù)據(jù)情情況下執(zhí)行行速度卻非非常慢：select*fromrecordwheresubstrb(CardNo,1,4)='5378'(13秒)select*fromrecordwhereamount/30<1000（11秒）select*fromrecordwhereto_char(ActionTime,'yyyymmdd')='19991201'（10秒）SQL優(yōu)化(oracle)避免對列的的操作由于where子句中對列列的任何操操作結(jié)果都都是在SQL運(yùn)行時(shí)逐行行計(jì)算得到到的，因此此它不得不不進(jìn)行表掃掃描，而沒沒有使用該該列上面的的索引；如如果這些結(jié)結(jié)果在查詢詢編譯時(shí)就就能得到，，那么就可可以被SQL優(yōu)化器優(yōu)化化，使用索索引，避免免表掃描，，因此將SQL重寫如下：：select*fromrecordwhereCardNolike'5378%'（<1秒）select*fromrecordwhereamount<1000*30（<1秒）select*fromrecordwhereActionTime=to_date('1999120差別是很明顯的！SQL優(yōu)化(oracle)避免不必要要的類型轉(zhuǎn)轉(zhuǎn)換需要注意的的是，盡量量避免潛在在的數(shù)據(jù)類類型轉(zhuǎn)換。。如將字符符型數(shù)據(jù)與與數(shù)值型數(shù)數(shù)據(jù)比較，，ORACLE會自動將字字符型用to_number()函數(shù)進(jìn)行轉(zhuǎn)轉(zhuǎn)換，從而而導(dǎo)致全表表掃描。例2：表tab1中的列col1是字符型（（char)，則以下語語句存在類類型轉(zhuǎn)換：：selectcol1,col2fromtab1wherecol1>10，應(yīng)該寫為：：selectcol1,col2fromtab1wherecol1>'10'。SQL優(yōu)化(oracle)增加查詢的的范圍限制制增加查詢的的范圍限制制，避免全全范圍的搜搜索。例3：以下查詢詢表record中時(shí)間ActionTime小于2001年3月1日的數(shù)據(jù)：：select*fromrecordwhereActionTime<to_date('20010301','yyyymm')查詢計(jì)劃表表明，上面面的查詢對對表進(jìn)行全全表掃描，，如果我們們知道表中中的最早的的數(shù)據(jù)為2001年1月1日，那么，，可以增加加一個(gè)最小小時(shí)間，使使查詢在一一個(gè)完整的的范圍之內(nèi)內(nèi)。修改如如下：SQL優(yōu)化(oracle)增加查詢的的范圍限制制select*fromrecordwhereActionTime<to_date('20010301','yyyymm')andActionTime>to_date('20010101','yyyymm')后一種SQL語句將利用用上ActionTime字段上的索索引，從而而提高查詢詢效率。把把'20010301'換成一個(gè)變變量，根據(jù)據(jù)取值的機(jī)機(jī)率，可以以有一半以以上的機(jī)會會提高效率率。同理，，對于大于于某個(gè)值的的查詢，如如果知道當(dāng)當(dāng)前可能的的最大值，，也可以在在Where子句中加上上“AND列名<MAX(最大值)”。SQL優(yōu)化(oracle)盡量去掉"IN"、"OR“含有"IN"、"OR"的Where子句常會使使用工作表表，使索引引失效；如如果不產(chǎn)生生大量重復(fù)復(fù)值，可以以考慮把子子句拆開；；拆開的子子句中應(yīng)該該包含索引引。例4：selectcount(*)fromstuffwhereid_noin('0','1')（23秒）可以考慮將將or子句分開：：selectcount(*)fromstuffwhereid_no='0'selectcount(*)fromstuffwhereid_no='1'然后再做一一個(gè)簡單的的加法，與與原來的SQL語句相比，，查詢速度度更快。SQL優(yōu)化(oracle)盡量去掉"<>“盡量去掉"<>"，避免全表表掃描，如如果數(shù)據(jù)是是枚舉值，，且取值范范圍固定，，則修改為為"OR"方式。例5：UPDATESERVICEINFOSETSTATE=0WHERESTATE<>0;以上語句由由于其中包包含了"<>"，執(zhí)行計(jì)劃劃中用了全全表掃描（（TABLEACCESSFULL），沒有用用到state字段上的索索引。實(shí)際際應(yīng)用中，，由于業(yè)務(wù)務(wù)邏輯的限限制，字段段state為枚舉值，，只能等于于0，1或2，而且，值值等于=1，2的很少，因因此可以去去掉"<>"，利用索引引來提高效效率。修改為：UPDATESERVICEINFOSETSTATE=0WHERESTATE=1ORSTATE=2。進(jìn)一步的的修改可以以參考第4種方法。SQL優(yōu)化(oracle)去掉Where子句中的ISNULL和ISNOTNULLWhere字句中的ISNULL和ISNOTNULL將不會使用用索引而是是進(jìn)行全表表搜索，因因此需要通通過改變查查詢方式，，分情況討討論等方法法，去掉Where子句中的ISNULL和ISNOTNULL。SQL優(yōu)化(oracle)索引提高數(shù)數(shù)據(jù)分布不不均勻時(shí)查查詢效率索引的選擇擇性低，但但數(shù)據(jù)的值值分布差異異很大時(shí)，，仍然可以以利用索引引提高效率率。A、數(shù)據(jù)分布布不均勻的的特殊情況況下，選擇擇性不高的的索引也要要?jiǎng)?chuàng)建。表ServiceInfo中數(shù)據(jù)量很很大，假設(shè)設(shè)有一百萬萬行，其中中有一個(gè)字字段DisposalCourseFlag，取值范圍圍為枚舉值值：[0，1，2，3，4，5，6，7]。按照前面面說的索引引建立的規(guī)規(guī)則，“選選擇性不高高的字段不不應(yīng)該建立立索引，該該字段只有有8種取值，索索引值的重重復(fù)率很高高，索引選選擇性明顯顯很低，因因此不建索索引。然而而，由于該該字段上數(shù)數(shù)據(jù)值的分分布情況非非常特殊，，具體如下下表：SQL優(yōu)化(oracle)索引提高數(shù)數(shù)據(jù)分布不不均勻時(shí)查查詢效率而且，常用用的查詢中中，查詢DisposalCourseFlag<6的情況既多多又頻繁，，毫無疑問問，如果能能夠建立索索引，并且且被應(yīng)用，，那么將大大大提高這這種情況的的查詢效率率。因此，，我們需要要在該字段段上建立索索引。SQL優(yōu)化(oracle)利用HINT強(qiáng)制指定索索引在ORACLE優(yōu)化器無法法用上合理理索引的情情況下，利利用HINT強(qiáng)制指定索索引。繼續(xù)上面7的例子，ORACLE缺省認(rèn)定，，表中列的的值是在所所有數(shù)據(jù)行行中均勻分分布的，也也就是說，，在一百萬萬數(shù)據(jù)量下下，每種DisposalCourseFlag值各有12.5萬數(shù)據(jù)行與與之對應(yīng)。。假設(shè)SQL搜索條件DisposalCourseFlag=2，利用DisposalCourseFlag列上的索引引進(jìn)行數(shù)據(jù)據(jù)搜索效率率，往往不不比全表掃掃描的高，，ORACLE因此對索引引“視而不不見”，從從而在查詢詢路徑的選選擇中，用用其他字段段上的索引引甚至全表表掃描。根根據(jù)我們上上面的分析析，數(shù)據(jù)值值的分布很很特殊，嚴(yán)嚴(yán)重的不均均勻。SQL優(yōu)化(oracle)利用HINT強(qiáng)制指定索索引為了利用索索引提高效效率，此時(shí)時(shí)，一方面面可以單獨(dú)獨(dú)對該字段段或該表用用analyze語句進(jìn)行分分析，對該該列搜集足足夠的統(tǒng)計(jì)計(jì)數(shù)據(jù)，使使ORACLE在查詢選擇擇性較高的的值時(shí)能用用上索引；；另一方面，，可以利用用HINT提示，在SELECT關(guān)鍵字后面面，加上““/*+INDEX(表名稱，索索引名稱））*/”的方式，強(qiáng)強(qiáng)制ORACLE優(yōu)化器用上上該索引。。比如：select*fromserviceinfowhereDisposalCourseFlag=1;SQL優(yōu)化(oracle)利用HINT強(qiáng)制指定索索引上面的語句句，實(shí)際執(zhí)執(zhí)行中ORACLE用了全表掃掃描，加上上藍(lán)色提示示部分后，，用到索引引查詢。如如下：select/*+INDEX(SERVICEINFO,IX_S_DISPOSALCOURSEFLAG)*/*fromserviceinfowhereDisposalCourseFlag=1;請注意，這這種方法會會加大代碼碼維護(hù)的難難度，而且且該字段上上索引的名名稱被改變變之后，必必須要同步步所有指定定索引的HINT代碼，否則則HINT提示將被ORACLE忽略掉。SQL優(yōu)化(oracle)屏蔽無用索索引繼續(xù)上面8的例子，由由于實(shí)際查查詢中，還還有涉及到到DisposalCourseFlag=6的查詢，而而此時(shí)如果果用上該字字段上的索索引，將是是非常不明明智的，效效率也極低低。因此這這種情況下下，我們需需要用特殊殊的方法屏屏蔽該索引引，以便ORACLE選擇其他字字段上的索索引。比如如，如果字字段為數(shù)值值型的就在在表達(dá)式的的字段名后后，添加““+0”，為字符型型的就并上上空串：““||""””如：select*fromserviceinfowhereDisposalCourseFlag+0=6andworkNo='36'。不過，不要要把該用的的索引屏蔽蔽掉了，否否則同樣會會產(chǎn)生低效效率的全表表掃描。SQL優(yōu)化(oracle)分解復(fù)雜查查詢，用常常量代替變變量對于復(fù)雜的的Where條件組合，，Where中含有多個(gè)個(gè)帶索引的的字段，考考慮用IF語句分情況況進(jìn)行討論論；同時(shí)，，去掉不必必要的外來來參數(shù)條件件，減低復(fù)復(fù)雜度，以以便在不同同情況下用用不同字段段上的索引引。SQL優(yōu)化(oracle)分解復(fù)雜查查詢，用常常量代替變變量繼續(xù)上面9的例子，對對于包含Where(DisposalCourseFlag<v_DisPosalCourseFlag)or(v_DisPosalCourseFlagisnull)and....的查詢，(這里v_DisPosalCourseFlag為一個(gè)輸入入變量，取取值范圍可可能為[NULL，0，1，2，3，4，5，6，7])，可以考慮慮分情況用用IF語句進(jìn)行討討論，類似似：IFv_DisPosalCourseFlag=1THENWhereDisposalCourseFlag=1and....ELSIFv_DisPosalCourseFlag=2THENWhereDisposalCourseFlag=2and....。。。。。。。SQL優(yōu)化(oracle)like子句盡量前前端匹配因?yàn)閘ike參數(shù)使用的的非常頻繁繁，因此如如果能夠?qū)ike子句使用索索引，將很很高的提高高查詢的效效率。例6：select*fromcitywherenamelike‘‘%S%’’以上上查查詢詢的的執(zhí)執(zhí)行行計(jì)計(jì)劃劃用用了了全全表表掃掃描描（（TABLEACCESSFULL），如果能夠夠修改為：select*fromcitywherenamelike‘‘S%’那么查詢的執(zhí)執(zhí)行計(jì)劃將會會變成（INDEXRANGESCAN），成功的利利用了name字段的索引。。這意味著OracleSQL優(yōu)化器會識別別出用于索引引的like子句，只要該該查詢的匹配配端是具體值值。因此我們們在做like查詢時(shí)，應(yīng)該該盡量使查詢詢的匹配端是是具體值，即即使用like‘‘S%’。SQL優(yōu)化(oracle)用Case語句合并多重重掃描我們常常必須須基于多組數(shù)數(shù)據(jù)表計(jì)算不不同的聚集。。例如下例通通過三個(gè)獨(dú)立立查詢：例8：1）selectcount(*)fromempwheresal<1000;2）selectcount(*)fromempwheresalbetween1000and5000;3）selectcount(*)fromempwheresal>5000;這樣我們需要要進(jìn)行三次全全表查詢，但但是如果我們們使用case語句：SQL優(yōu)化(oracle)用Case語句合并多重重掃描selectcount(salewhensal<1000then1elsenullend)count_poor,count(salewhenbetween1000and5000then1elsenullend)count_blue_collar,count(salewhensal>5000then1elsenullend)count_poorfromemp;這樣查詢的結(jié)結(jié)果一樣，但但是執(zhí)行計(jì)劃劃只進(jìn)行了一一次全表查詢詢SQL優(yōu)化(oracle)使用nls_date_format例9：select*fromrecordwhereto_char(ActionTime,'mm')='12'這個(gè)查詢的執(zhí)執(zhí)行計(jì)劃將是是全表查詢，，如果我們改改變nls_date_format，SQL>alertsessionsetnls_date_formate=’MM’;現(xiàn)在重新修改改上面的查詢詢：select*fromrecordwhereActionTime='12'這樣就能使用用actiontime上的索引了，，它的執(zhí)行計(jì)計(jì)劃將是（INDEXRANGESCAN）SQL優(yōu)化(oracle)使用基于函數(shù)數(shù)的索引前面談到任何何對列的操作作都可能導(dǎo)致致全表掃描，，例如：select*fromempwheresubstr(ename,1,2)=’SM’’;但是這種查詢詢在客服系統(tǒng)統(tǒng)又經(jīng)常使用用，我們可以以創(chuàng)建一個(gè)帶帶有substr函數(shù)的基于函函數(shù)的索引，，createindexemp_ename_substroneemp(substr(ename,1,2));這樣在執(zhí)行上上面的查詢語語句時(shí)，這個(gè)個(gè)基于函數(shù)的的索引將排上上用場，執(zhí)行行計(jì)劃將是（（INDEXRANGESCAN）。SQL優(yōu)化(oracle)基于函數(shù)的索索引要求等式式匹配上面的例子中中，我們創(chuàng)建建了基于函數(shù)數(shù)的索引，但但是如果執(zhí)行行下面的查詢詢：select*fromempwheresubstr(ename,1,1)=’S’得到的執(zhí)行計(jì)計(jì)劃將還是（（TABLEACCESSFULL），因?yàn)橹挥杏挟?dāng)數(shù)據(jù)列能能夠等式匹配配時(shí)，基于函函數(shù)的索引才才能生效，這這樣對于這種種索引的計(jì)劃劃和維護(hù)的要要求都很高。。請注意，向向表中添加索索引是非常危危險(xiǎn)的操作，，因?yàn)檫@將導(dǎo)導(dǎo)致許多查詢詢執(zhí)行計(jì)劃的的變更。然而而，如果我們們使用基于函函數(shù)的索引就就不會產(chǎn)生這這樣的問題，，因?yàn)镺racle只有在查詢使使用了匹配的的內(nèi)置函數(shù)時(shí)時(shí)才會使用這這種類型的索索引。SQL優(yōu)化(oracle)使用分區(qū)索引引在用分析命令令對分區(qū)索引引進(jìn)行分析時(shí)時(shí)，每一個(gè)分分區(qū)的數(shù)據(jù)值值的范圍信息息會放入Oracle的數(shù)據(jù)字典中中。Oracle可以利用這個(gè)個(gè)信息來提取取出那些只與與SQL查詢相關(guān)的數(shù)數(shù)據(jù)分區(qū)。例如，假設(shè)你你已經(jīng)定義了了一個(gè)分區(qū)索索引，并且某某個(gè)SQL語句需要在一一個(gè)索引分區(qū)區(qū)中進(jìn)行一次次索引掃描。。Oracle會僅僅訪問這這個(gè)索引分區(qū)區(qū)，而且會在在這個(gè)分區(qū)上上調(diào)用一個(gè)此此索引范圍的的快速全掃描描。因?yàn)椴恍栊枰L問整個(gè)個(gè)索引，所以以提高了查詢詢的速度。SQL優(yōu)化(oracle)使用位圖索引引位圖索引可以以從本質(zhì)上提提高使用了小小于1000個(gè)唯一數(shù)據(jù)值值的數(shù)據(jù)列的的查詢速度，，因?yàn)樵谖粓D圖索引中進(jìn)行行的檢索是在在RAM中完成的，而而且也總是比比傳統(tǒng)的B樹索引的速度度要快。對于于那些少于1000個(gè)唯一數(shù)據(jù)值值的數(shù)據(jù)列建建立位圖索引引，可以使執(zhí)執(zhí)行效率更快快。SQL優(yōu)化(oracle)決定使用全表表掃描還是使使用索引和所有的秘笈笈一樣，最后后一招都會又又回到起點(diǎn)，，最后我們來來討論一下是是否需要建立立索引，也許許進(jìn)行全表掃掃描更快。在在大多數(shù)情況況下，全表掃掃描可能會導(dǎo)導(dǎo)致更多的物物理磁盤輸入入輸出，但是是全表掃描有有時(shí)又可能會會