视窗
loading...
您现在的位置:首页 > IT认证 > oracle认证 >

Oracle中如何避免使用特定错误索引


有的时候,使用错误的索引会导致Oracle数据库的效率明显下降,通过一些方法或者是技巧可以有效的避免这个问题:

  这个例子中,如果我想使用idx_a而不是idx_b.

   SQL> create table test
  2 (a int,b int,c int,d int);
  Table created.
  SQL> begin
  2 for i in 1..50000
  3 loop
  4 insert into mytest values(i,i,i,i);
  5 end loop;
  6 commit;
  7 end;
  8 /
  PL/SQL procedure successfully completed.
  SQL> create index idx_a on mytest(a,b,c);
  Index created.
  SQL> create index idx_b on mytest(b);
  Index created.

  如表mytest,有字段a,b,c,d,在a,b,c上建立联合索引idx_a(a,b,c),在b上单独建立了一个索引idx_b(b)。

  在正常情况下,where a=? and b=? and c=?会用到索引idx_a,where b=?会用到索引idx_b

  比如:

   SQL> analyze table mytest compute statistics;
  Table analyzed.
  SQL> select num_Rows from user_tables where table_name='MYTEST';
  NUM_ROWS
  ----------
  50000
  SQL> select distinct_keys from user_indexes where index_name='IDX_A';
  DISTINCT_KEYS
  -------------
  50000
  SQL> set autotrace traceonly
  SQL> select d from mytest
  2 where a=10 and b=10 and c=10;
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 1542625214
  --------------------------------------------------------------------------------
  ------
  | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
  |
  --------------------------------------------------------------------------------
  ------
  | 0 | SELECT STATEMENT | | 1 | 16 | 2 (0)| 00:0
  0:01 |
  | 1 | TABLE ACCESS BY INDEX ROWID| MYTEST | 1 | 16 | 2 (0)| 00:0
  0:01 |
  |* 2 | INDEX RANGE SCAN | IDX_A | 1 | | 1 (0)| 00:0
  0:01 |
  --------------------------------------------------------------------------------
  ------
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  2 - access("A"=10 AND "B"=10 AND "C"=10)
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block gets
  4 consistent gets
  0 physical reads
  0 redo size
  508 bytes sent via SQL*Net to client
  492 bytes received via SQL*Net from client
  2 SQL*Net roundtrips to/from client
  0 sorts (memory)
  0 sorts (disk)
  1 rows processed
  SQL> select d from mytest
  2 where b=500;
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 530004086
  --------------------------------------------------------------------------------
  ------
  | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
  |
  --------------------------------------------------------------------------------
  ------
  | 0 | SELECT STATEMENT | | 1 | 8 | 2 (0)| 00:0
  0:01 |
  | 1 | TABLE ACCESS BY INDEX ROWID| MYTEST | 1 | 8 | 2 (0)| 00:0
  0:01 |
  |* 2 | INDEX RANGE SCAN | IDX_B | 1 | | 1 (0)| 00:0
  0:01 |
  --------------------------------------------------------------------------------
  ------
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  2 - access("B"=500)
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block gets
  4 consistent gets
  0 physical reads
  0 redo size
  508 bytes sent via SQL*Net to client
  492 bytes received via SQL*Net from client
  2 SQL*Net roundtrips to/from client
  0 sorts (memory)
  0 sorts (disk)
  1 rows processed

但是在这样一个条件下:where a=? and b=? and c=? group by b会用到哪个索引呢?在索引的分析数据不正确(很长时间没有分析)或根本没有分析数据的情况下,oracle往往会使用索引idx_b。通过执行计划的分析,这个索引的使用,将大大耗费查询时间。

  比如在索引有统计信息,分析数据正确的情况下:

  SQL> select max(d) from mytest
  2 where a=50 and b=50 and c=50
  3 group by b;
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 422688974
  --------------------------------------------------------------------------------
  -------
  | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Tim
  e |
  --------------------------------------------------------------------------------
  -------
  | 0 | SELECT STATEMENT | | 1 | 16 | 2 (0)| 00:
  00:01 |
  | 1 | SORT GROUP BY NOSORT | | 1 | 16 | 2 (0)| 00:
  00:01 |
  | 2 | TABLE ACCESS BY INDEX ROWID| MYTEST | 1 | 16 | 2 (0)| 00:
  00:01 |
  |* 3 | INDEX RANGE SCAN | IDX_A | 1 | | 1 (0)| 00:
  00:01 |
  --------------------------------------------------------------------------------
  -------
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  3 - access("A"=50 AND "B"=50 AND "C"=50)
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block gets
  3 consistent gets
  0 physical reads
  0 redo size
  513 bytes sent via SQL*Net to client
  492 bytes received via SQL*Net from client
  2 SQL*Net roundtrips to/from client
  0 sorts (memory)
  0 sorts (disk)
  1 rows processed
  但如果索引分析数据不正确:
  SQL> select num_rows from user_tables
  2 where table_name='MYTEST';
  NUM_ROWS
  ----------
  50000
  SQL> analyze index idx_a delete statistics;
  Index analyzed.
  SQL> analyze index idx_b delete statistics;
  Index analyzed.
  SQL> select distinct_keys from user_indexes
  2 where index_name in ('IDX_A','IDX_B');
  DISTINCT_KEYS
  -------------
  SQL> select max(d) from mytest where a=50 and b=50 and c=50 group by b;
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 3925507835
  --------------------------------------------------------------------------------
  -------
  | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Tim
  e |
  --------------------------------------------------------------------------------
  -------
  | 0 | SELECT STATEMENT | | 1 | 16 | 2 (0)| 00:
  00:01 |
  | 1 | SORT GROUP BY NOSORT | | 1 | 16 | 2 (0)| 00:
  00:01 |
  |* 2 | TABLE ACCESS BY INDEX ROWID| MYTEST | 1 | 16 | 2 (0)| 00:
  00:01 |
  |* 3 | INDEX RANGE SCAN | IDX_B | 1 | | 1 (0)| 00:
  00:01 |
  --------------------------------------------------------------------------------
  -------
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  2 - filter("A"=50 AND "C"=50)
  3 - access("B"=50)
  Statistics
  ----------------------------------------------------------
  0 recursive calls
  0 db block gets
  3 consistent gets
  0 physical reads
  0 redo size
  513 bytes sent via SQL*Net to client
  492 bytes received via SQL*Net from client
  2 SQL*Net roundtrips to/from client
  0 sorts (memory)
  0 sorts (disk)
  1 rows processed

  我们可以通过如下的技巧避免使用idx_b,而使用idx_a

      where a=? and b=? and c=? group by b||'' --如果b是字符类型
  where a=? and b=? and c=? group by b+0 --如果b是数字类型

  通过这样简单的改变,往往可以是查询时间提交很多倍

  当然,我们也可以使用no_index提示,相信很多人没有用过,也是一个不错的方法

    SQL> select /*+ no_index(mytest,idx_b) */ max(d) from mytest where a=50 and b=50 and c=50 group by b;
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 422688974
  --------------------------------------------------------------------------------
  -------
  | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Tim
  e |
  --------------------------------------------------------------------------------
  -------
  | 0 | SELECT STATEMENT | | 1 | 16 | 9 (0)| 00:
  00:01 |
  | 1 | SORT GROUP BY NOSORT | | 1 | 16 | 9 (0)| 00:
  00:01 |
  | 2 | TABLE ACCESS BY INDEX ROWID| MYTEST | 1 | 16 | 9 (0)| 00:
  00:01 |
  |* 3 | INDEX RANGE SCAN | IDX_A | 500 | | 1 (0)| 00:
  00:01 |
  --------------------------------------------------------------------------------
  -------
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  3 - access("A"=50 AND "B"=50 AND "C"=50)
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block gets
  3 consistent gets
  0 physical reads
  0 redo size
  513 bytes sent via SQL*Net to client
  492 bytes received via SQL*Net from client
  2 SQL*Net roundtrips to/from client
  0 sorts (memory)
  0 sorts (disk)
  1 rows processed

闂傚倷绶氬ḿ褍螞瀹€鍕;闁跨噦鎷�

闂傚倷绶氬ḿ褍螞瀹€鍕;闁跨噦鎷�

闂傚倷绶氬ḿ褍螞濞嗘挸绀夐柡鍥ュ灩閸屻劑鏌曢崼婵囧閻庢艾顭烽弻銊モ攽閸℃ê鐝旂紓浣瑰敾缂嶄線寮婚敓鐘茬妞ゆ劧瀵岄埀顒侇殜閺岀喖鎽庨崒姘ギ闂佽鍟崶褔鍞堕梺缁樻煥閹芥粎绮旈鍕厽闁绘ê寮堕幖鎰版煟鎺抽崝灞藉祫闂佺鎻粻鎴g箽闂備浇娉曢崳锕傚箯閿燂拷
闂傚倷绀侀幖顐︽偋濠婂牆绀堟繛鎴欏灪閸嬬喐銇勯弽顐沪闁绘帡绠栭弻鏇熺箾閸喖濮庨梺璇叉唉椤曆嗗絹闂佹悶鍎荤徊鑺ユ櫠閹绘崡褰掓偂鎼淬垹娈楅悗娈垮枛閻栧吋淇婇悜鑺ユ櫆闁告挆鍐帗婵犵數鍋涢悺銊у垝瀹€鈧懞閬嶆嚃閳哄嫬小婵炲鍘ч悺銊╁吹閸岀偞鐓涢柛鎰╁妼閳ь剝宕电划鏃囥亹閹烘挾鍙嗗┑鐐村灱濞呮洜鈧熬鎷�闂備浇顕уù鐑藉极閹间降鈧焦绻濋崑顖氱秺瀹曞崬螣鐠囧樊娼梻浣风串缁蹭粙寮甸鍕仼闁告鍊戞惔銊ョ倞闁挎繂鎳庨埛澶嬬箾鐎电ǹ甯堕柟铏耿閻涱喚鈧綆鍠栫粻锝嗙節婵犲倸顏柟鏋姂濮婃椽宕ㄦ繝鍐f嫻缂備礁顑嗙敮锟犲箚閸ャ劌顕遍柡澶嬪灥閸炪劑姊洪幖鐐插姌闁告柨绉归敐鐐哄冀椤儱閰e畷鍫曟晲閸涱厸鎷ゅ┑鐐差嚟閸樠囧箠濮椻偓楠炲棝宕橀鑲╊槹濡炪倖鍔戦崹娲儊閺冣偓缁绘繈濮€閿濆棛銆愰柣搴㈣壘閹芥粌危閹扮増鏅搁柨鐕傛嫹闂傚倷鑳堕幊鎾绘偤閵娾晛鍨傞柛鎰ゴ閸亪鏌熺€电ǹ小闁绘帒锕ら埞鎴︽偐閸欏鎮欏┑鐐叉噷閸ㄥ綊婀侀梺鎸庣箓濡盯鎯屾惔銊︾厓鐟滄粓宕滃▎鎾崇疇闁归偊鍏橀弸鏃堟煙鏉堥箖妾柛瀣儔閺屾盯顢曢妶鍛€剧紓鍌氱М閸嬫捇姊绘担鐟扮亰闁绘帪绠撴俊鐢告倷閻㈢數顦梺鍝勫暙閻楀棛鐥閺屾盯骞囬娑氥€婄紓浣插亾闁跨噦鎷�闂備浇顕х花鑲╁緤婵犳熬缍栧鑸靛姇閸ㄥ倹绻濇繝鍌氼伀妞も晠鏀遍妵鍕箳閹存繃娈茬紓浣风贰閸o絽顕i崼鏇熷€烽柛顭戝亝閻濐亜鈹戦悙鑼闁搞劌澧庣划姘舵焼瀹ュ懐鍔撮梺鍛婂壃閸涱垼妲繝鐢靛Х椤d粙鍩€椤掆偓閸熷潡鍩€椤掑倹鍤€闁挎洏鍨洪幏鍛村礈閹绘帗顓块梻浣呵归張顒傛崲瀹ュ鑸归柟缁㈠枟閻撴瑩鎮楀☉娆嬬細濠⒀屽墯缁绘繈鍩€椤掍焦濯撮柛锔诲幘閹虫繈姊洪崜鑼帥闁稿鎳愮槐鐐哄焵椤掑嫭鈷戦柣鐔稿閹界娀鏌eΔ鍐ㄤ户闁瑰箍鍨归~婵嬵敄閼恒儳浜欓梻浣告惈濞诧箓鎯岄鐐床闁糕剝绋掗悡娆愩亜閹炬鍟版禒鏉戭渻閵堝棙澶勯柛鎾跺枎閻g兘鏁愰崱娆戠槇闂佸憡鍔忛弲鈺佄i鐐粹拺闁奸€涘嵆閸濈儤鎱ㄦ繝鍌ょ吋闁哄苯鐗撻獮姗€顢欓懖鈺婂悈闂備胶鎳撻悺銊у垝瀹ュ洤鍨濋柨鏇炲€归悡銉︾箾閹寸倖鎴濓耿閻楀牏绡€闁逞屽墴楠炲秹顢欓幆褍瑙︽繝鐢靛仜濡霉妞嬪海鐜绘俊銈呭暟绾惧ジ鏌¢崒娑卞劌闁稿骸绻掗埀顒冾潐閹哥ǹ螞濠靛棛鏆︽慨妯垮煐閸嬫劗绱撴担璐細鐟滅増鍨垮娲箰鎼粹€虫灆闂佺懓鍤栭幏锟�闂備浇顕уù鐑藉极閹间礁绠犻柟鎹愬煐閺嗘粍銇勯幇鍓佺暠缂佲偓閸℃ḿ绠鹃柟瀵镐紳椤忓牆鏋侀柛顐f礃閸婄數鐥鐐村婵炲吋鍔欓弻娑㈠Ω閿斿墽鐓佺紓浣稿€圭敮锟犮€佸Δ浣瑰缂佸鏅濋锔解拺閻熸瑥瀚欢鑼磼缂佹ê鐏寸€殿噮鍋婇、娆撴偩瀹€濠冪カ婵犳鍠楅妵娑㈠磻閹剧粯鐓冪憸婊堝礈濞嗘挸纾归柛婵勫劤缁€濠囨倵閿濆骸鏋熼柛搴$Ч閺屾盯寮撮妸銉ョ瑢閻熸粎澧楃敮妤呮偂閳ь剙顪冮妶鍡楃瑨闁挎洩濡囩划鍫ユ晸閿燂拷闂傚倷娴囨竟鍫熴仈缁嬫娼栧┑鐘崇閻掗箖鏌熺紒銏犳灈婵☆偅锕㈤弻锝夋偄缁嬫妫嗙紒缁㈠幐閸嬫捇姊绘担鐟邦嚋缂佸甯掗悾婵嬪箹娴e摜锛涢梺鍝勭Р閸斿酣銆呴悜鑺ョ叆闁绘洖鍊圭€氾拷:webmaster@jscj.com闂傚倷绶氬ḿ褍螞瀹€鍕;闁瑰墽绮悡鐔搞亜椤愵偄骞樼紒浣哄厴閺岋綁鏁傜捄銊х厯闂佽桨绀佺粔褰掑极閹剧粯鏅搁柨鐕傛嫹4008816886

相关文章

无相关信息
更新时间2022-03-13 11:05:03【至顶部↑】
联系我们 | 邮件: webmaster@jscj.com | 客服热线电话:4008816886(QQ同号) |  婵犵數濮烽弫鎼佸磿閹寸姷绀婇柍褜鍓氶妵鍕即閸℃顏柛娆忕箻閺岋綁骞囬鍛瘜闂佺ǹ顑嗛幑鍥偘椤曗偓瀹曞綊顢欓崣銉ф/濠电姷鏁告慨顓㈠磻閹剧粯鐓曢柕澶嬪灥閼活垰鈻撻銏╂富闁靛牆妫欓ˉ鍡樸亜閺傚尅鍔熼柟骞垮灲閺佹捇鏁撻敓锟�

付款方式留言簿投诉中心网站纠错二维码手机版

客服电话: