2. 程式人生 > >oracle 優化之組合索引

oracle 優化之組合索引

阿新 • • 發佈：2018-11-12

組合索引適用場景：

1.適用在單獨查詢返回記錄很多，組合查詢後忽然返回記錄很少的情況:

比如where 學歷=碩士以上 返回不少的記錄
比如where 職業=收銀員 同樣返回不少的記錄
於是無論哪個條件查詢做索引，都不合適。
可是，如果學歷為碩士以上，同時職業又是收銀員的，返回的就少之又少了。
於是聯合索引就可以這麼開始建了。

 2.組合查詢的組合順序，要考慮單獨的字首查詢情況（否則單獨字首查詢的索引不能生效或者只能用到跳躍索引）
比如你在建id,object_type的聯合索引時，要看考慮是單獨where id=xxx查詢的多，還是單獨where object_type查詢的多。
這裡細節就暫時略去了，在案例的部分中還有描述

 

3.僅等值無範圍查詢時，組合索引順序不影響效能（比如where col1=xxx and col2=xxx，無論COL1+COL2組合還是COL2+COL1組合）

drop table t purge;
create table t as select * from dba_objects;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
update t set object_id=rownum ;
commit;
create index idx_id_type on t(object_id,object_type);
create index idx_type_id on t(object_type,object_id);
set autotrace off
alter session set statistics_level=all ;
set linesize 366

create index idx_id_type on t(object_id,object_type);
create index idx_type_id on t(object_type,object_id);
set autotrace off
alter session set statistics_level=all ;
set linesize 200

select /*+index(t,idx_id_type)*/ * from t where object_id=20 and object_type='TABLE';
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID 7qydm6x641kx4, child number 1
-------------------------------------
select /*+index(t,idx_id_type)*/ * from t where object_id=20 and
object_type='TABLE'

Plan hash value: 1470938839

-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 1 |00:00:00.01 | 5 |

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 1 | 1 |00:00:00.01 | 5 |
|* 2 | INDEX RANGE SCAN | IDX_ID_TYPE | 1 | 1 | 1 |00:00:00.01 | 4 |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("OBJECT_ID"=20 AND "OBJECT_TYPE"='TABLE')

Note
-----

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- cardinality feedback used for this statement


24 rows selected.

可以看出走的是索引範圍掃描，並且回表。

 

--4.組合索引最佳順序一般是將列等值查詢的列置前。

（測試組合索引在條件是不等的情況下的情況，條件經常是不等的，要放在後面，讓等值的在前面）


Execution Plan
----------------------------------------------------------
Plan hash value: 1470938839

-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 16 | 3312 | 52 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 16 | 3312 | 52 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_ID_TYPE | 50 | | 51 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("OBJECT_ID">=20 AND "OBJECT_TYPE"='TABLE' AND "OBJECT_ID"<2000)
filter("OBJECT_TYPE"='TABLE')

Note
-----
- dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
89 consistent gets
0 physical reads
0 redo size
51596 bytes sent via SQL*Net to client
875 bytes received via SQL*Net from client
34 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
493 rows processed

通過索引快速掃面獲得行ID進行回表。

 

5.注意組合索引與組合條件中關於IN 的優化

 

案例1

UPDATE t SET OBJECT_ID=20 WHERE ROWNUM<=26000;
UPDATE t SET OBJECT_ID=21 WHERE OBJECT_ID<>20;
COMMIT;
set linesize 1000
set pagesize 1
alter session set statistics_level=all ;
select /*+index(t,idx1_object_id)*/ * from t where object_TYPE='TABLE' AND OBJECT_ID >= 20 AND OBJECT_ID<= 21;

Execution Plan
----------------------------------------------------------
Plan hash value: 3420768628

-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 20755 | 4195K| 1186 (1)| 00:00:15 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 20755 | 4195K| 1186 (1)| 00:00:15 |
|* 2 | INDEX RANGE SCAN | IDX_TYPE_ID | 20755 | | 218 (0)| 00:00:03 |
-------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("OBJECT_TYPE"='TABLE' AND "OBJECT_ID">=20 AND "OBJECT_ID"<=21)

Note
-----
- dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
5059 consistent gets
0 physical reads
0 redo size
1191984 bytes sent via SQL*Net to client
18464 bytes received via SQL*Net from client
1633 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
24472 rows processed

 

 

 select  /*+index(t,idx1_object_id)*/ * from t  where object_TYPE='TABLE'  AND OBJECT_ID in (20,21);

 

 

以上兩個語句：

select  /*+index(t,idx1_object_id)*/ * from t  where object_TYPE='TABLE'  AND OBJECT_ID >= 20 AND OBJECT_ID<= 21;     --CPU cost消耗1186

select /*+index(t,idx1_object_id)*/ * from t where object_TYPE='TABLE' AND OBJECT_ID in (20,21);               -- CPU cost消耗僅僅為5 

為何消耗的CPU成本差距這麼大？ 

 在人為的思考中，我們人為認為 (OBJECT_ID >= 20 AND OBJECT_ID<= 21) = in (20,21),而其實oracle 不這麼認為in (20,21) 只有兩個值，而(OBJECT_ID >= 20 AND OBJECT_ID<= 21)走索引中間有無窮個鍵值。所以第二句消耗的CPU COST僅僅為5。

 

6.依然是關於IN的優化 (col1,col2,col3的索引情況，如果沒有為COL2賦予查詢條件時，COL3只能起到檢驗作用)

 

drop table t purge;
create table t as select * from dba_objects;
UPDATE t SET OBJECT_ID=20 WHERE ROWNUM<=26000;
UPDATE t SET OBJECT_ID=21 WHERE OBJECT_ID<>20;
Update t set object_id=22 where rownum<=10000;
COMMIT;

create index idx_union on t(object_type,object_id,owner);
set autotrace traceonly

 

select * from t where object_type='VIEW' and OWNER='SYS';
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

Execution Plan
----------------------------------------------------------
Plan hash value: 1570829420

-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3369 | 681K| 20 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 3369 | 681K| 20 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_UNION | 14 | | 19 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

2 - access("OBJECT_TYPE"='VIEW' AND "OWNER"='SYS')
filter("OWNER"='SYS')

Note
-----
- dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
686 consistent gets
0 physical reads
0 redo size
157650 bytes sent via SQL*Net to client
3405 bytes received via SQL*Net from client
264 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3938 rows processed

SQL>

23 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3713220770

----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY_CURSOR | 8168 | 16336 | 29 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
27 recursive calls
0 db block gets
136 consistent gets
0 physical reads
0 redo size
1925 bytes sent via SQL*Net to client
534 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
23 rows processed

 

select /*+INDEX(T,idx_union)*/ * from t T where object_type='VIEW' and OBJECT_ID IN (20,21,22) AND OWNER='SYS';
select * from table(dbms_xplan.display_cursor(null,null,'allstats last'));

Execution Plan
----------------------------------------------------------
Plan hash value: 306189815

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3369 | 681K| 6 (0)| 00:00:01 |
| 1 | INLIST ITERATOR | | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| T | 3369 | 681K| 6 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | IDX_UNION | 1 | | 5 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

3 - access("OBJECT_TYPE"='VIEW' AND ("OBJECT_ID"=20 OR "OBJECT_ID"=21 OR
"OBJECT_ID"=22) AND "OWNER"='SYS')

Note
-----
- dynamic sampling used for this statement (level=2)


Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
687 consistent gets
0 physical reads
0 redo size
157650 bytes sent via SQL*Net to client
3405 bytes received via SQL*Net from client
264 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3938 rows processed

SQL>
23 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 3713220770

----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY_CURSOR | 8168 | 16336 | 29 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------


Statistics
----------------------------------------------------------
15 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
1862 bytes sent via SQL*Net to client
534 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
23 rows processed

 可以看出，select * from t where object_type='VIEW' and OWNER='SYS'; 這一條語句跟select /*+INDEX(T,idx_union)*/ * from t T where object_type='VIEW' and OBJECT_ID IN (20,21,22) AND OWNER='SYS';這一條語句代價等價，因為此案例中object_type='VIEW' 且OBJECT_ID 只有20,21,22 這三條記錄，所以如果沒有為COL2賦予查詢條件時，COL3只能起到檢驗作用。

相關推薦

oracle 優化之組合索引

組合索引適用場景： 1.適用在單獨查詢返回記錄很多，組合查詢後忽然返回記錄很少的情況: 比如where 學歷=碩士以上 返回不少的記錄 比如where 職業=收銀員 同樣返回不少的記錄 於是無論哪個條件查詢做索引，都不合適。 可是，如果學歷為碩士以上，同時職業又是收銀員的，返回的就少之又少了。 於是聯合

數據查詢優化之mysql索引

between 如果 哪些 isa 綜合 ring 信息 xpl xxx 為什麽要建立索引： 索引用於快速找出在某個列中有一特定值的行。不使用索引，MySQL必須從第1條記錄開始然後讀完整個表直到找出相關的行，還需要考慮每次讀入數據頁的IO開銷。而如果采取索引，則可以根據索

Mysql性能優化之覆蓋索引

查找 cnblogs 都是 記錄 性能優化 nod 如果 libary 使用 因為我們大多數情況下使用的都是Innodb，所以這篇博客主要依據Innodb來講 b+樹（圖片來自網絡）

Sql Sever效能優化之指定索引

背景：生產環境SQL語句查詢過慢（資料總量在350萬左右），日誌中心一直報警 解決過程：分析無果後，求助於公司的DBA，DBA分析後建議在語句中指定索引 解決：在SQL語句中指定索引，效果相當明顯，親測有效 優化前SQL： SELECT ROW_NUMBER() OVER ( ORDER BY

Oracle優化之單表分頁優化

單表分頁優化思路： --建立測試表： SQL> create table t_test as select * from dba_objects; Table created. 如，下面的sql （沒有過濾條件，只有排序），要將查詢結果分頁顯示，每頁顯示10條，如： select * from

資料庫查詢效能優化之利器—索引

一.索引的概念 　　廣義的索引是指：將具有檢索意義的事項按照一定方式排列，以方便進行檢索。資料庫中的索引是指：將資料庫表中的一列或者多列按照一定的方式進行組織以方便對資料庫表中的內容進行查詢。 　　字典是廣義的索引最好的例子，比如我們在字典中查詢"陳"字，有兩種查詢方

MySQL SQL優化之覆蓋索引

內容概要 利用主索引提升SQL的查詢效率是我們經常使用的一個技巧，但是有些時候MySQL給出的執行計劃卻完全出乎我們的意料，我們預想MySQL會通過索引掃描完成查詢，但是MySQL給出的執行計劃卻是通過全表掃描完成查詢的，其中的某些場景我們可以利用覆蓋索引進行優化。

Mysql之組合索引

對於任何DBMS，索引都是進行優化的最主要的因素。對於少量的資料，沒有合適的索引影響不是很大，但是，當隨著資料量的增加，效能會急劇下降。  如果對多列進行索引(組合索引)，列的順序非常重要，MySQL僅能對索引最左邊的字首進行有效的查詢。例如：  假設存在組合索引(c1,

【MySQL】效能優化之 覆蓋索引

mysql中的一種十分高效有用的索引---覆蓋索引。 覆蓋索引用通俗的話講就是在select的時候只用去讀取索引而取得資料，無需進行二次select相關表。這樣的索引的葉子節點上面也包含了他們索引的資料。 select * from table_name； select id，name from table_

【Oracle index】組合索引如何選擇前導列的幾點考慮

選擇組合索引的前導列，必須根據具體的業務（SQL）寫法和列的資料分佈不同而不同，很多書或網上都說，前導列要選擇高選擇性的，但是，脫離具體的業務，這些是沒有意義的，本文就舉一些常見的例子來分析下如何正確選擇前導列,以拋磚引玉，實際應用中，有更多複雜的情況需要具體分析。1.都是

oracle 索引優化之distinct

11G R2環境： --DISTINCT測試前的準備drop table t purge;create table t as select * from dba_objects;update t set object_id=rownum;alter table T modify OBJECT_ID not n

oracle 優化--索引

數據庫應用 oracle create 程序 原則性 一、事務1、簡介事務是數據處理的核心，是業務上的一個邏輯單元，它能夠保證其中對數據所有的操作，要麽全部成功，要麽全部失敗。DBMS通過事務的管理來協調用戶的並發行為，減少用戶訪問資源的沖突。 1）顯示提交：當事務遇到COMMIT指令時，

oracle數據庫優化之統計信息

oracle性能優化1.統計信息簡介統計信息主要是描述數據庫中表，索引的大小，規模，數據分布狀況等的一類信息。比如，表的行數，塊數，平均每行的大小，索引的leaf blocks，索引字段的行數，不同值的大小等，都屬於統計信息。CBO正是根據這些統計信息數據，計算出不同訪問路徑下，不同join 方式下，各種計劃

mysql優化之索引

總結 例如 drop mysql5 建立 語句 運算操作 空間 耗時 Mysql優化之使用索引 1,索引簡介 索引是單獨一種數據結構，單獨存在的一個空間。可以把數據表裏的建立了索引的字段，進和物理地址，存在在一塊，這塊空間就是‘索引’。 查詢數據先從索引中查詢，查詢到之後，

數據庫優化之創建索引

索引 sql 楊書凡 索引提供指針以指向存儲在表中指定列的數據，然後根據指定的次序排列這些指針，在根據指針到達包含該值的行什麽是索引 數據庫中的索引和數據的目錄相似，利用目錄快速查找所需的信息。在數據庫中，索引是某個表中一列或者若幹列值的集合，以及物流標識這些值的數據頁的邏輯指針清單

mysql數據庫-查詢優化之索引篇

mys 結構 details 速查 dex 主鍵 alt key 數據結構 定義：是數據庫中專門用於幫助用戶快速查詢數據的一種數據結構。類似於字典中的目錄，查找字典內容時可以根據目錄查找到數據的存放位置，然後直接獲取即可。 分類：普通索引，唯一性索引，全文索引，單列索引，多

1.數據庫優化之索引

索引數據 mysql 數據庫 索引：索引是存儲引擎用來快速找到記錄的一種數據結構。同樣，這也是索引的基本功能。 索引對良好的性能非常重要，尤其是當數據量越來越大時，良好的索引設計愈發重要。如果索引設計的不合理，性能反而會下降。 索引優化應該是對查詢優化最有效的手段了，索引可以輕易的將查詢性能提升幾

mysql數據庫優化之 如何選擇合適的列建立索引

索引 taf order 誰的 bsp 選擇 spa mysql 查詢 1. 在where 從句，group by 從句，order by 從句，on 從句中出現的列； 2. 索引字段越小越好； 3. 離散度大的列放到聯合索引的前面；比如： select * fro

mysql性能優化之索引優化（轉）

形式 字符串類 b樹索引 基礎 var 開發 null -- mysql服務器 作為免費又高效的數據庫，mysql基本是首選。良好的安全連接，自帶查詢解析、sql語句優化，使用讀寫鎖（細化到行）、事物隔離和多版本並發控制提高並發，完備的事務日誌記錄，強大的存儲引擎提供高效查

MySQL(三) —— MySQL效能優化之 索引優化

MySQL索引優化 如何選擇合適的列建立索引？ 在where從句、group by 從句、order by 從句、on 從句中出現的列 索引欄位越小越好 離散度大的列放在聯合索引的前面 如何判斷列的離散度？ 去重查詢看列的唯一值，唯一值越多則離散度越大。 mysql&