數據庫系統是管理(lǐ)信息系統的(de)核心，基于數據庫的(de)聯機事務處理(lǐ)（OLTP）以及聯機分(fēn)析處理(lǐ)(OLAP)是銀行(xíng)、企業(yè)、政府等部門最爲重要的(de)計(jì)算機應用(yòng)之一。從大(dà)多數系統的(de)應用(yòng)實例來看，查詢操作在各種數據庫操作中所占據的(de)比重最大(dà)，而查詢操作所基于的(de)SELECT語句在SQL語句中又(yòu)是代價最大(dà)的(de)語句。舉例來說，如(rú)果數據的(de)量積累到(dào)一定的(de)程度，比如(rú)一個(gè)銀行(xíng)的(de)賬戶數據庫表信息積累到(dào)上(shàng)百萬甚至上(shàng)千萬條記錄，全表掃描一次往往需要數十分(fēn)鍾，甚至數小(xiǎo)時。如(rú)果采用(yòng)比全表掃描更好的(de)查詢策略，往往可(kě)以使查詢時間降爲幾分(fēn)鍾，由此可(kě)見查詢優化技術(shù)的(de)重要性。
在應用(yòng)項目的(de)實施中發現，許多程序員在利用(yòng)一些前端數據庫開(kāi)發工(gōng)具（如(rú)PowerBuilder、Delphi等）開(kāi)發數據庫應用(yòng)程序時，隻注重用(yòng)戶界面的(de)華麗(lì)，并不重視查詢語句的(de)效率問題，導緻所開(kāi)發出來的(de)應用(yòng)系統效率低下，資源浪費嚴重。因此，如(rú)何設計(jì)高(gāo)效合理(lǐ)的(de)查詢語句就顯得非常重要。本文(wén)以應用(yòng)實例爲基礎，結合數據庫理(lǐ)論，介紹查詢優化技術(shù)在現實系統中的(de)運用(yòng)。
分(fēn)析問題
許多程序員認爲查詢優化是DBMS（數據庫管理(lǐ)系統）的(de)任務，與程序員所編寫的(de)SQL語句關系不大(dà)，這是錯誤的(de)。一個(gè)好的(de)查詢計(jì)劃往往可(kě)以使程序性能(néng)提高(gāo)數十倍。查詢計(jì)劃是用(yòng)戶所提交的(de)SQL語句的(de)集合，查詢規劃是經過優化處理(lǐ)之後所産生的(de)語句集合。DBMS處理(lǐ)查詢計(jì)劃的(de)過程是這樣的(de)：在做完查詢語句的(de)詞法、語法檢查之後，将語句提交給DBMS的(de)查詢優化器(qì)，優化器(qì)做完代數優化和(hé)存取路(lù)徑的(de)優化之後，由預編譯模塊對語句進行(xíng)處理(lǐ)并生成查詢規劃，然後在合适的(de)時間提交給系統處理(lǐ)執行(xíng)，最後将執行(xíng)結果返回給用(yòng)戶。在實際的(de)數據庫産品(如(rú)Oracle、Sybase等)的(de)高(gāo)版本中都(dōu)是采用(yòng)基于代價的(de)優化方法，這種優化能(néng)根據從系統字典表所得到(dào)的(de)信息來估計(jì)不同的(de)查詢規劃的(de)代價，然後選擇一個(gè)較優的(de)規劃。雖然現在的(de)數據庫産品在查詢優化方面已經做得越來越好，但(dàn)由用(yòng)戶提交的(de)SQL語句是系統優化的(de)基礎，很難設想一個(gè)原本糟糕的(de)查詢計(jì)劃經過系統的(de)優化之後會(huì)變得高(gāo)效，因此所寫語句的(de)優劣至關重要。下面重點說明(míng)改善查詢計(jì)劃的(de)解決方案。 
 

解決問題
下面以關系數據庫系統Informix爲例，介紹改善用(yòng)戶查詢計(jì)劃的(de)方法。

1．合理(lǐ)使用(yòng)索引
索引是數據庫中重要的(de)數據結構，它的(de)根本目的(de)就是爲了提高(gāo)查詢效率。現在大(dà)多數的(de)數據庫産品都(dōu)采用(yòng)IBM最先提出的(de)ISAM索引結構。索引的(de)使用(yòng)要恰到(dào)好處，其使用(yòng)原則如(rú)下：
●在經常進行(xíng)連接，但(dàn)是沒有(yǒu)指定爲外鍵的(de)列上(shàng)建立索引，而不經常連接的(de)字段則由優化器(qì)自動生成索引。
●在頻繁進行(xíng)排序或分(fēn)組（即進行(xíng)group by或order by操作）的(de)列上(shàng)建立索引。
●在條件(jiàn)表達式中經常用(yòng)到(dào)的(de)不同值較多的(de)列上(shàng)建立檢索，在不同值少(shǎo)的(de)列上(shàng)不要建立索引。比如(rú)在雇員表的(de)“性别”列上(shàng)隻有(yǒu)“男”與“女(nǚ)”兩個(gè)不同值，因此就無必要建立索引。如(rú)果建立索引不但(dàn)不會(huì)提高(gāo)查詢效率，反而會(huì)嚴重降低更新速度。
●如(rú)果待排序的(de)列有(yǒu)多個(gè)，可(kě)以在這些列上(shàng)建立複合索引（compound index）。
●使用(yòng)系統工(gōng)具。如(rú)Informix數據庫有(yǒu)一個(gè)tbcheck工(gōng)具，可(kě)以在可(kě)疑的(de)索引上(shàng)進行(xíng)檢查。在一些數據庫服務器(qì)上(shàng)，索引可(kě)能(néng)失效或者因爲頻繁操作而使得讀(dú)取效率降低，如(rú)果一個(gè)使用(yòng)索引的(de)查詢不明(míng)不白地(dì)慢(màn)下來，可(kě)以試著(zhe)用(yòng)tbcheck工(gōng)具檢查索引的(de)完整性，必要時進行(xíng)修複。另外，當數據庫表更新大(dà)量數據後，删除并重建索引可(kě)以提高(gāo)查詢速度。

2．避免或簡化排序
應當簡化或避免對大(dà)型表進行(xíng)重複的(de)排序。當能(néng)夠利用(yòng)索引自動以适當的(de)次序産生輸出時，優化器(qì)就避免了排序的(de)步驟。以下是一些影響因素：
●索引中不包括一個(gè)或幾個(gè)待排序的(de)列；
●group by或order by子句中列的(de)次序與索引的(de)次序不一樣；
●排序的(de)列來自不同的(de)表。
爲了避免不必要的(de)排序，就要正确地(dì)增建索引，合理(lǐ)地(dì)合并數據庫表（盡管有(yǒu)時可(kě)能(néng)影響表的(de)規範化，但(dàn)相(xiàng)對于效率的(de)提高(gāo)是值得的(de)）。如(rú)果排序不可(kě)避免，那麽應當試圖簡化它，如(rú)縮小(xiǎo)排序的(de)列的(de)範圍等。

3．消除對大(dà)型表行(xíng)數據的(de)順序存取
在嵌套查詢中，對表的(de)順序存取對查詢效率可(kě)能(néng)産生緻命的(de)影響。比如(rú)采用(yòng)順序存取策略，一個(gè)嵌套3層的(de)查詢，如(rú)果每層都(dōu)查詢1000行(xíng)，那麽這個(gè)查詢就要查詢10億行(xíng)數據。避免這種情況的(de)主要方法就是對連接的(de)列進行(xíng)索引。例如(rú)，兩個(gè)表：學生表（學号、姓名、年齡……）和(hé)選課表（學号、課程号、成績）。如(rú)果兩個(gè)表要做連接，就要在“學号”這個(gè)連接字段上(shàng)建立索引。
還可(kě)以使用(yòng)并集來避免順序存取。盡管在所有(yǒu)的(de)檢查列上(shàng)都(dōu)有(yǒu)索引，但(dàn)某些形式的(de)where子句強迫優化器(qì)使用(yòng)順序存取。下面的(de)查詢将強迫對orders表執行(xíng)順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num&