關於複合索引中的2個索引列誰在前誰在後的進一步討論--實踐篇，索引--

關於複合索引中的2個索引列誰在前誰在後的進一步討論--實踐篇，索引--

關於複合索引中的2個索引列誰在前誰在後的進一步討論--實踐篇：

上一次在長老的QQ群裡邊說了這麼一個例子：

create table test_pk( id varchar2(10), create_dt date);alter table test_pk modify (id varchar2 (30 ));insert into test_pk select object_id, sysdate from dba_objects;

commit

需要執行的查詢是：

select * from test_pk where create_dt> sysdate- 1/1440 and id like '13%'

索引有如下兩個：當然任意時刻，只存在下面的任意一個。

create index idx_test_pk on test_pk(create_dt, id);create index idx_test_pk_id_create_dt on test_pk(id,create_dt);

 

也就是說：兩個索引列的位置是反著的

首先要明確的一個問題：

where create_dt> sysdate- 1/1440 and id like '13%'
不論 create_dt 和id 誰在前誰在後，這樣的where條件是能走索引的。

 

其次需要明確的問題：
create_dt 和id  這兩個索引列，哪個在前面時，如上查詢的效率高？（當然，前提是：不考慮其他查詢！！！）

經過實際驗證，發現id 在前面時，如上查詢的buffer get要比 create_dt 在前面時的 buffer get 低。

 

create index idx_test_pk_id_create_dt on test_pk(id,create_dt); ---bg 是 6

 

 create index idx_test_pk on test_pk(create_dt,id); ---bg 是29.5

那麼為啥id 在前面時的複合索引，查詢語句的buffer get 要低呢？
原因不在於 id是什麼資料類型的，
原因在於where條件中id的表現形式： id like '13%' ，相比而言，create_dt的表現形式是create_dt> sysdate- 1/1440

大家知道：
index是有序的，那麼 id like '13%' 去索引的leaf block 檢索時，檢索過的leaf block的數量 一般是要比 create_dt> sysdate- 1/1440 （也就是create_dt在前面） 去索引的leaf block 檢索過的leaf bock 的數量要少，正是這個原因，才導致id列在前面時的buffer get 要小。