表DYN_DAYAHEAD_BID按时间data_time分区，有5个分区，建立了一个本地分区索引index ind_dyn_daybid_store，索引列是data_time, tag_phy, tag_app,version四个字段。

专注于为中小企业提供成都网站建设、网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业天柱免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了成百上千企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

一直以来，觉得JDBC Update修改数据时特别慢(根据业务逻辑，往往是一次update 481条记录)。今天trace了应用程序的执行计划（应用程序通过jdbc访问数据库，数据库版本为oracle 9.2.0.1）。通过jdbc的执行计划（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下执行类似的语句，则明显的使用了索引：

 
 
 

  
  
  
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，强制使用索引，然后程序的执行计划如下：

 
 
 

  
  
  
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) 
 
 
 

现在看起来是JDBC Update使用了索引，但好像对索引进行全表扫描，跟查询和在sqlplus下使用范围扫描不一样。

由于现在表中的数据比较少，就已经很慢了，以后更加不可能接受，请教各位，为什么在程序中没有正确的使用索引，有什么解决的方法吗？

谢谢大家！

分享标题：浅谈使用JDBCUpdate时不能使用索引的原因
转载来于：http://www.scanyue.cn/article/cdogggp.html