建站
咨詢
售后
建站咨詢
新聞中心
這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
淺談使用JDBCUpdate時不能使用索引的原因
表DYN_DAYAHEAD_BID按時間data_time分區(qū)，有5個分區(qū)，建立了一個本地分區(qū)索引index ind_dyn_daybid_store，索引列是data_time, tag_phy, tag_app,version四個字段。
專注于為中小企業(yè)提供成都網(wǎng)站建設、網(wǎng)站建設服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)天柱免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
一直以來，覺得JDBC Update修改數(shù)據(jù)時特別慢(根據(jù)業(yè)務邏輯，往往是一次update 481條記錄)。今天trace了應用程序的執(zhí)行計劃（應用程序通過jdbc訪問數(shù)據(jù)庫，數(shù)據(jù)庫版本為oracle 9.2.0.1）。通過jdbc的執(zhí)行計劃（trace文件)如下：
- select Data_Time,Tag_Phy,Tag_App,Value_0,Value_1,Value_2,Value_3,Value_4,
- Value_5,Value_6,Value_7,Value_8,Value_9,Version
- from
- DYN_DAYAHEAD_BID where Tag_Phy = :1 and version = :2 and Data_Time > :3 and
- Data_Time <= :4+1 and Tag_App in ('5TMS01DBS07','5TMS01DBS08','5TMS01DBS09',
- '5TMS01DBS10','5TMS01DBS11','5TMS01DBS12')
- call count cpu elapsed disk query current rows
- ------- ------ -------- ---------- ---------- ---------- ---------- ----------
- Parse 1 0.00 0.00 0 0 0 0
- Execute 1 0.00 0.00 0 0 0 0
- Fetch 49 0.04 0.02 0 609 0 481
- ------- ------ -------- ---------- ---------- ---------- ---------- ----------
- total 51 0.04 0.02 0 609 0 481
- Misses in library cache during parse: 1
- Optimizer goal: CHOOSE
- Parsing user id: 62
- Rows Row Source Operation
- ------- ---------------------------------------------------
- 481 PARTITION RANGE ITERATOR PARTITION: 1 KEY
- 481 TABLE ACCESS BY LOCAL INDEX ROWID DYN_DAYAHEAD_BID PARTITION: 1 KEY
- 481 INDEX RANGE SCAN IND_DYN_DAYBID_STORE PARTITION: 1 KEY (object id 30391)
- ....
- update DYN_DAYAHEAD_BID set Value_0 = :1 , Value_1 = :2 , Value_2 = :3 ,
- Value_3 = :4 , Value_4 = :5 , Value_5 = :6 , Value_6 = :7 , Value_7 = :8 ,
- Value_8 = :9 , Value_9 = :10
- where
- Data_Time= :11 and Tag_Phy= :12 and Tag_App= :13 and Version= :14
- call count cpu elapsed disk query current rows
- ------- ------ -------- ---------- ---------- ---------- ---------- ----------
- Parse 481 0.02 0.03 0 0 0 0
- Execute 481 12.85 13.23 346 277537 500 481
- Fetch 0 0.00 0.00 0 0 0 0
- ------- ------ -------- ---------- ---------- ---------- ---------- ----------
- total 962 12.87 13.26 346 277537 500 481
- Misses in library cache during parse: 1
- Optimizer goal: CHOOSE
- Parsing user id: 62
- Rows Row Source Operation
- ------- ---------------------------------------------------
- 0 UPDATE
- 1 PARTITION RANGE ALL PARTITION: 1 5
- 1 TABLE ACCESS FULL DYN_DAYAHEAD_BID PARTITION: 1 5
顯然，查詢時是JDBC Update用到了索引，而修改時JDBC Update沒有使用索引，但我在sqlplus下執(zhí)行類似的語句，則明顯的使用了索引：
- SQL> update DYN_DAYAHEAD_BID set value_0=111
- where data_time=to_date('2006-04-14 0:15:00','yyyy-mm-dd hh24:mi:ss')
- and tag_phy='303101120211' and tag_app='5TMS01DBS07' and version=1
- SQL> /
JDBC Update已更新 1 行。
- Execution Plan
- ----------------------------------------------------------
- 0 UPDATE STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=51)
- 1 0 UPDATE OF 'DYN_DAYAHEAD_BID'
- 2 1 INDEX (UNIQUE SCAN) OF 'IND_DYN_DAYBID_STORE' (UNIQUE) (
- Cost=1 Card=1 Bytes=51)
然后，我對程序中的sql語句增加了hint，強制使用索引，然后程序的執(zhí)行計劃如下：
- update /*+ INDEX(dyn_dayahead_bid ind_dyn_daybid_store) */ DYN_DAYAHEAD_BID
- set Value_0 = :1 , Value_1 = :2 , Value_2 = :3 , Value_3 = :4 , Value_4 =
- :5 , Value_5 = :6 , Value_6 = :7 , Value_7 = :8 , Value_8 = :9 , Value_9 =
- :10
- where
- Data_Time= :11 and Tag_Phy= :12 and Tag_App= :13 and Version= :14
- call count cpu elapsed disk query current rows
- ------- ------ -------- ---------- ---------- ---------- ---------- ----------
- Parse 481 0.04 0.02 0 0 0 0
- Execute 481 11.37 11.48 0 247234 502 481
- Fetch 0 0.00 0.00 0 0 0 0
- ------- ------ -------- ---------- ---------- ---------- ---------- ----------
- total 962 11.41 11.50 0 247234 502 481
- Misses in library cache during parse: 0
- Optimizer goal: CHOOSE
- Parsing user id: 62
- Rows Row Source Operation
- ------- ---------------------------------------------------
- 0 UPDATE
- 1 PARTITION RANGE ALL PARTITION: 1 5
- 1 INDEX FULL SCAN IND_DYN_DAYBID_STORE PARTITION: 1 5 (object id 30391)
現(xiàn)在看起來是JDBC Update使用了索引，但好像對索引進行全表掃描，跟查詢和在sqlplus下使用范圍掃描不一樣。
由于現(xiàn)在表中的數(shù)據(jù)比較少，就已經(jīng)很慢了，以后更加不可能接受，請教各位，為什么在程序中沒有正確的使用索引，有什么解決的方法嗎？
謝謝大家！
本文題目：淺談使用JDBCUpdate時不能使用索引的原因
網(wǎng)站網(wǎng)址：http://m.5511xx.com/article/cdogggp.html
