自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Oracle數(shù)據(jù)庫效率技巧:避免錯(cuò)誤的索引

數(shù)據(jù)庫 Oracle
Oracle數(shù)據(jù)庫中是數(shù)據(jù)庫索引在Oracle數(shù)據(jù)庫中發(fā)揮著很大的作用,正是數(shù)據(jù)庫索引的使用加快了Oracle數(shù)據(jù)庫的工作效率,當(dāng)然使用索引時(shí)必須得選擇正確了,相反,如果使用了錯(cuò)誤的數(shù)據(jù)庫索引,不但不能夠加快Oracle數(shù)據(jù)庫工作效率,還會(huì)帶來不好的影響。

導(dǎo)讀:有的時(shí)候,使用錯(cuò)誤的索引會(huì)導(dǎo)致Oracle數(shù)據(jù)庫的效率明顯下降,通過一些方法或者是技巧可以有效的避免這個(gè)問題,下文中就為大家?guī)肀苊馐褂缅e(cuò)誤的數(shù)據(jù)庫索引的,以提高Oracle數(shù)據(jù)庫的工作效率。

  這個(gè)例子中,如果我想使用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上建立聯(lián)合索引idx_a(a,b,c),在b上單獨(dú)建立了一個(gè)索引idx_b(b)。

  在正常情況下,where a=? and b=? and c=?會(huì)用到索引idx_a,where b=?會(huì)用到索引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
 

#p#

 

  但是在這樣一個(gè)條件下:where a=? and b=? and c=? group by b會(huì)用到哪個(gè)索引呢?在索引的分析數(shù)據(jù)不正確(很長時(shí)間沒有分析)或根本沒有分析數(shù)據(jù)的情況下,oracle往往會(huì)使用索引idx_b。通過執(zhí)行計(jì)劃的分析,這個(gè)索引的使用,將大大耗費(fèi)查詢時(shí)間。

  比如在索引有統(tǒng)計(jì)信息,分析數(shù)據(jù)正確的情況下:

  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

 

  但如果索引分析數(shù)據(jù)不正確:

  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

#p#

 

  我們可以通過如下的技巧避免使用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是數(shù)字類型

  通過這樣簡單的改變,往往可以是查詢時(shí)間提交很多倍

  當(dāng)然,我們也可以使用no_index提示,相信很多人沒有用過,也是一個(gè)不錯(cuò)的方法:

  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

上文中主要是以代碼的形式為大家講解的,看起來可能是不太容易理解,大家要深入其中去學(xué)習(xí),這個(gè)技巧是非常實(shí)用的,希望大家能夠從中收獲。

【編輯推薦】

  1. 詳解Oracle數(shù)據(jù)庫備份不同的恢復(fù)特性
  2. 由淺入深講解MySQL數(shù)據(jù)庫索引的選擇性
  3. Oracle數(shù)據(jù)庫11g創(chuàng)非集群基準(zhǔn)測試世界紀(jì)錄
  4. Oracle數(shù)據(jù)庫開發(fā)技術(shù)經(jīng)驗(yàn)淺談
責(zé)任編輯:迎迎 來源: IT專家網(wǎng)論壇
相關(guān)推薦

2010-04-07 17:45:22

Oracle位圖索引

2011-03-16 08:54:45

Oracle數(shù)據(jù)庫索引

2010-10-27 14:15:44

Oracle數(shù)據(jù)庫效率

2010-04-06 11:19:28

Oracle數(shù)據(jù)庫

2011-04-02 09:33:08

MySQL數(shù)據(jù)庫查詢效率

2011-04-02 09:33:13

MySQL數(shù)據(jù)庫查詢效率

2011-04-02 09:23:19

MySQL數(shù)據(jù)庫查詢效率

2009-05-18 13:18:54

字符Oracle字符串

2023-11-16 17:12:33

數(shù)據(jù)庫oracle

2010-04-21 11:43:33

Oracle數(shù)據(jù)庫

2011-09-02 10:06:51

OracleSqlLoad常用技巧

2010-03-18 09:28:14

Oracle數(shù)據(jù)庫遷移

2010-04-19 13:31:42

Oracle索引

2011-03-01 16:30:55

Oracle

2011-03-17 14:09:25

Oracle數(shù)據(jù)庫字符

2011-03-11 16:25:53

Oracle數(shù)據(jù)庫

2011-04-13 16:48:56

索引數(shù)據(jù)庫

2010-05-10 18:54:12

Oracle數(shù)據(jù)庫索引

2010-04-26 14:24:58

Oracle數(shù)據(jù)庫索引

2011-03-17 16:35:20

Oracle數(shù)據(jù)庫段管理
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號