在開發(fā)應(yīng)用程序時(shí)，如果SQL查詢優(yōu)化的語(yǔ)句設(shè)計(jì)得不好，可能就會(huì)很嚴(yán)重地影響到應(yīng)用程序的性能。因此我們?cè)陂_發(fā)應(yīng)用程序時(shí)，一定要慎用SQL的查詢語(yǔ)句，盡可能地把SQL查詢優(yōu)化做到***。

本文我們通過(guò)一個(gè)實(shí)例來(lái)告訴大家在開發(fā)應(yīng)用程序及執(zhí)行SQL查詢優(yōu)化語(yǔ)句時(shí)的一些思路，實(shí)例如下：在某銀行做校園卡繳費(fèi)的測(cè)試過(guò)程中，發(fā)現(xiàn)成功繳費(fèi)時(shí)間很長(zhǎng)，大約需要75秒左右，原因分析：在做校園卡繳費(fèi)的時(shí)候，首先是從數(shù)據(jù)庫(kù)中查詢到需要繳費(fèi)的費(fèi)項(xiàng)，然后再對(duì)該費(fèi)項(xiàng)進(jìn)行繳費(fèi)，繳費(fèi)成功后修改相應(yīng)的狀態(tài)，交易完成后，查看日志，發(fā)現(xiàn)下面的查詢語(yǔ)句執(zhí)行時(shí)間很長(zhǎng)，在數(shù)據(jù)庫(kù)中執(zhí)行時(shí)間大約74.516秒，可見幾乎所有的時(shí)間都花在查詢上。

select b.stu_id, b.term_id, b.cost_code  
 
from bib_booking_student_info a, bib_booking_fee_info b  
 
where a.busi_id = b.busi_id  
 
and a.corp_id = b.corp_id  
 
and a.term_id = b.term_id  
 
and a.stu_id = b.stu_id  
 
and b.stu_stat = '0' 
 
and a.busi_id = '100104' 
 
and a.corp_id = 'E000000059' 
 
and a.term_id = '0101' 
 
and a.stu_id = '59000030'; 

解決辦法，優(yōu)化此SQL語(yǔ)句（說(shuō)實(shí)話，這個(gè)SQL寫得真不好，只是實(shí)現(xiàn)了功能，完全沒有考慮性能，尤其當(dāng)數(shù)據(jù)庫(kù)大的時(shí)候），下面是優(yōu)化后的SQL語(yǔ)句：

select b.stu_id, b.term_id, b.cost_code  
 
from bib_booking_fee_info b  
 
where b.stu_stat = '0' 
 
and exists( select 1 from bib_booking_student_info a where  
 
a.corp_id = b.corp_id  
 
and a.term_id = b.term_id  
 
and a.stu_id = b.stu_id  
 
and a.busi_id = b.busi_id  
 
and a.busi_id = '100104' 
 
and a.corp_id = 'E000000059' 
 
and a.term_id = '0101' 
 
and a.stu_id = '59000030' 
 
) 

此語(yǔ)句執(zhí)行時(shí)間只有0.219秒，快了很多很多。

總結(jié)：在類似于這種交易，先查詢?cè)倮U費(fèi)（改變字段狀態(tài)）的交易，執(zhí)行查詢時(shí)間的多少直接影響到此交易的性能。假如只是做插入，不做查詢的交易，這種交易一般都很快，有查詢，然后再繳費(fèi)（改變字段狀態(tài)）的交易，如果響應(yīng)時(shí)間很慢，那需要在查詢SQL語(yǔ)句上進(jìn)行優(yōu)化了。

關(guān)于SQL查詢優(yōu)化的知識(shí)就介紹這么多，希望能夠帶給您一些收獲吧！

【編輯推薦】

1. 談一談Oracle WDP計(jì)劃和Oracle認(rèn)證
2. 關(guān)于Oracle利用UTL_INADDR注入的簡(jiǎn)單介紹
3. 登陸Oracle 10g控制臺(tái)時(shí)提示IO失常錯(cuò)誤的解決方案
4. Oracle數(shù)據(jù)庫(kù)中各種類型的文件損壞與修復(fù)過(guò)程詳解
5. 簡(jiǎn)單介紹一下Oracle ERP上線后的迅捷管教和新功能