这篇文章主要介绍“使用JDBC Update时不能使用索引的原因是什么”，在日常操作中，相信很多人在使用JDBC Update时不能使用索引的原因是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”使用JDBC Update时不能使用索引的原因是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
创新互联专业为企业提供洛阳网站建设、洛阳做网站、洛阳网站设计、洛阳网站制作等企业网站建设、网页设计与制作、洛阳企业网站模板建站服务，10余年洛阳做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
表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 hh34: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下使用范围扫描不一样。
到此，关于“使用JDBC Update时不能使用索引的原因是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
