浅谈使用JDBCUpdate时不能使用索引的原因

表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文件)如下：

 
 
 
    
  
  
  
  1. select Data_Time,Tag_Phy,Tag_App,Value_0,Value_1,Value_2,Value_3,Value_4,  
    2.   
  
  
  2.   Value_5,Value_6,Value_7,Value_8,Value_9,Version   
    3.   
  
  
  3. from  
    4.   
  
  
  4. DYN_DAYAHEAD_BID where Tag_Phy = :1 and version = :2 and Data_Time > :3 and   
    5.   
  
  
  5.   Data_Time <= :4+1 and Tag_App in ('5TMS01DBS07','5TMS01DBS08','5TMS01DBS09',  
    6.   
  
  
  6.   '5TMS01DBS10','5TMS01DBS11','5TMS01DBS12')  
    7.   
  
  
  7.  
    8.   
  
  
  8.  
    9.   
  
  
  9. call     count       cpu    elapsed       disk      query    current        rows  
    10.   
  
  
  10. ------- ------  -------- ---------- ---------- ---------- ----------  ----------  
    11.   
  
  
  11. Parse        1      0.00       0.00          0          0          0           0  
    12.   
  
  
  12. Execute      1      0.00       0.00          0          0          0           0  
    13.   
  
  
  13. Fetch       49      0.04       0.02          0        609          0         481  
    14.   
  
  
  14. ------- ------  -------- ---------- ---------- ---------- ----------  ----------  
    15.   
  
  
  15. total       51      0.04       0.02          0        609          0         481  
    16.   
  
  
  16.  
    17.   
  
  
  17. Misses in library cache during parse: 1  
    18.   
  
  
  18. Optimizer goal: CHOOSE  
    19.   
  
  
  19. Parsing user id: 62    
    20.   
  
  
  20.  
    21.   
  
  
  21. Rows     Row Source Operation  
    22.   
  
  
  22. -------  ---------------------------------------------------  
    23.   
  
  
  23.     481  PARTITION RANGE ITERATOR PARTITION: 1 KEY   
    24.   
  
  
  24.     481   TABLE ACCESS BY LOCAL INDEX ROWID DYN_DAYAHEAD_BID PARTITION: 1 KEY   
    25.   
  
  
  25.     481    INDEX RANGE SCAN IND_DYN_DAYBID_STORE PARTITION: 1 KEY (object id 30391)  
    26.   
  
  
  26.  
    27.   
  
  
  27. ....  
    28.   
  
  
  28. update DYN_DAYAHEAD_BID set Value_0 = :1 , Value_1 = :2 , Value_2 = :3 ,   
    29.   
  
  
  29.   Value_3 = :4 , Value_4 = :5 , Value_5 = :6 , Value_6 = :7 , Value_7 = :8 ,   
    30.   
  
  
  30.   Value_8 = :9 , Value_9 = :10   
    31.   
  
  
  31. where  
    32.   
  
  
  32. Data_Time= :11 and Tag_Phy= :12 and Tag_App= :13 and Version= :14  
    33.   
  
  
  33.  
    34.   
  
  
  34.  
    35.   
  
  
  35. call     count       cpu    elapsed       disk      query    current        rows  
    36.   
  
  
  36. ------- ------  -------- ---------- ---------- ---------- ----------  ----------  
    37.   
  
  
  37. Parse      481      0.02       0.03          0          0          0           0  
    38.   
  
  
  38. Execute    481     12.85      13.23        346     277537        500         481  
    39.   
  
  
  39. Fetch        0      0.00       0.00          0          0          0           0  
    40.   
  
  
  40. ------- ------  -------- ---------- ---------- ---------- ----------  ----------  
    41.   
  
  
  41. total      962     12.87      13.26        346     277537        500         481  
    42.   
  
  
  42.  
    43.   
  
  
  43. Misses in library cache during parse: 1  
    44.   
  
  
  44. Optimizer goal: CHOOSE  
    45.   
  
  
  45. Parsing user id: 62    
    46.   
  
  
  46.  
    47.   
  
  
  47. Rows     Row Source Operation  
    48.   
  
  
  48. -------  ---------------------------------------------------  
    49.   
  
  
  49.       0  UPDATE    
    50.   
  
  
  50.       1   PARTITION RANGE ALL PARTITION: 1 5   
    51.   
  
  
  51.       1    TABLE ACCESS FULL DYN_DAYAHEAD_BID PARTITION: 1 5  
    52.

显然，查询时是JDBC Update用到了索引，而修改时JDBC Update没有使用索引，但我在sqlplus下执行类似的语句，则明显的使用了索引：

 
 
 
    
  
  
  
  1. SQL> update DYN_DAYAHEAD_BID set value_0=111 
    2.   
  
  
  2.      where data_time=to_date('2006-04-14 0:15:00','yyyy-mm-dd hh24:mi:ss')  
    3.   
  
  
  3.      and tag_phy='303101120211' and tag_app='5TMS01DBS07' and version=1 
    4.   
  
  
  4. SQL> / 
    5.

JDBC Update已更新 1 行。

 
 
 
    
  
  
  
  1. Execution Plan  
    2.   
  
  
  2. ----------------------------------------------------------  
    3.   
  
  
  3.    0      UPDATE STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=51)  
    4.   
  
  
  4.    1    0   UPDATE OF 'DYN_DAYAHEAD_BID'  
    5.   
  
  
  5.    2    1     INDEX (UNIQUE SCAN) OF 'IND_DYN_DAYBID_STORE' (UNIQUE) (  
    6.   
  
  
  6.           Cost=1 Card=1 Bytes=51) 
    7.

然后，我对程序中的sql语句增加了hint，强制使用索引，然后程序的执行计划如下：

 
 
 
    
  
  
  
  1. update  /*+ INDEX(dyn_dayahead_bid ind_dyn_daybid_store) */ DYN_DAYAHEAD_BID   
    2.   
  
  
  2.   set Value_0 = :1 , Value_1 = :2 , Value_2 = :3 , Value_3 = :4 , Value_4 =   
    3.   
  
  
  3.   :5 , Value_5 = :6 , Value_6 = :7 , Value_7 = :8 , Value_8 = :9 , Value_9 =   
    4.   
  
  
  4.   :10   
    5.   
  
  
  5. where  
    6.   
  
  
  6. Data_Time= :11 and Tag_Phy= :12 and Tag_App= :13 and Version= :14  
    7.   
  
  
  7.  
    8.   
  
  
  8.  
    9.   
  
  
  9. call     count       cpu    elapsed       disk      query    current        rows  
    10.   
  
  
  10. ------- ------  -------- ---------- ---------- ---------- ----------  ----------  
    11.   
  
  
  11. Parse      481      0.04       0.02          0          0          0           0  
    12.   
  
  
  12. Execute    481     11.37      11.48          0     247234        502         481  
    13.   
  
  
  13. Fetch        0      0.00       0.00          0          0          0           0  
    14.   
  
  
  14. ------- ------  -------- ---------- ---------- ---------- ----------  ----------  
    15.   
  
  
  15. total      962     11.41      11.50          0     247234        502         481  
    16.   
  
  
  16.  
    17.   
  
  
  17. Misses in library cache during parse: 0  
    18.   
  
  
  18. Optimizer goal: CHOOSE  
    19.   
  
  
  19. Parsing user id: 62    
    20.   
  
  
  20.  
    21.   
  
  
  21. Rows     Row Source Operation  
    22.   
  
  
  22. -------  ---------------------------------------------------  
    23.   
  
  
  23.       0  UPDATE    
    24.   
  
  
  24.       1   PARTITION RANGE ALL PARTITION: 1 5   
    25.   
  
  
  25.       1    INDEX FULL SCAN IND_DYN_DAYBID_STORE PARTITION: 1 5 (object id 30391) 
    26.

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

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

谢谢大家！

网站名称：浅谈使用JDBCUpdate时不能使用索引的原因
文章位置：http://www.zyruijie.cn/qtweb/news18/3068.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

Google知识

同城分类信息

vi形象设计　　 　成都西云机房　　 　h5页面制作　　 　德阳网站建设　　 　温江网站设计　　 　泸州洋跃建站　　 　阿坝网站建设　　 　自贡主机托管　　 　成都网站建设　　 　成都棕树机房　　 　重庆服务器托管　　 　南充网站建设　　 　微信小程序　　 　重庆网站建设　　 　企业微信定制　　 　解决方案　　 　什邡做网站　　 　注册域名　　 　成都网站建设　　 　手机APP开发