MySQL的字首索引及Oracle的類似實現

駐雲科技發表於2018-01-29

MySQL有一個很有意思的索引型別,叫做字首索引,它可以給某個文字欄位的前面部分單獨做索引,從而降低索引的大小。 其實,Oracle也有類似的實現,對於文字,它可以通過substr的函式索引,實現同樣甚至更多的功能。

MySQL有一個很有意思的索引型別,叫做字首索引,它可以給某個文字欄位的前面部分單獨做索引,從而降低索引的大小。

其實,Oracle也有類似的實現,對於文字,它可以通過substr的函式索引,實現同樣甚至更多的功能。另外,經過探索,我們發現,原來數字和時間欄位,在Oracle也可以實現類似的功能。

MySQL的字首索引

MySQL的字首索引指的是對指定的欄位的前面幾位建立的索引。

Altertable Table_Name add key(column_name(prefix_len));複製程式碼

或者

Createindex index_name on Table_Name(column_name(prefix_len));複製程式碼

建立字首索引後,可以直接當做普通索引進行過濾。

Select ..from table_name where column_name=’…’;複製程式碼

字首索引的最大的好處是降低索引的大小。另外,由於InnoDB單列索引長度不能超過767bytes,如果是text或者blob欄位,直接建立索引可能會報錯,而字首索引可以繞過這一限制。

做個測試看一下。

delimiter;;

dropFUNCTION if exists random_str;;

CREATEFUNCTION random_str(n int) RETURNS varchar(30000)  

begin         

declarereturn_str varchar(30000) default "";         

declare iint default 0; 

whilelength(return_str) < n do         

setreturn_str=concat(return_str,md5(rand())); 

endwhile;         

returnsubstring(return_str,1,n);     

end;;複製程式碼

首先,建立一個生成超過1000長度的隨機字串的函式。

建立測試表

CREATETABLE TEST_PREFIX_IND (

       ID INT(10) PRIMARY KEY AUTO_INCREMENT,

       NORMAL_STR VARCHAR(20) ,

       LONG_STR VARCHAR(1000),

       TEXT_STR TEXT,

       BLOB_STR BLOB

 );複製程式碼

插入10000行記錄:

drop  procedure if exists init_test_prefix_ind;;

createprocedure init_test_prefix_ind(n int)

begin         

declare iint default 0; 

while i< n do         

insertinto test_prefix_ind(NORMAL_STR,long_str,  TEXT_STR,BLOB_STR)

values(random_str(20),random_str(rand()*1000+1),random_str(rand()*1000+1),random_str(rand()*300+1));

seti=i+1;

endwhile;         

end;;

callinit_test_prefix_ind(10000);;複製程式碼

嘗試在型別為varchar(1000)的LONG_STR建立索引

altertable test_prefix_ind add key(LONG_STR);;複製程式碼

成功了,但是Sub_part顯示為767,表示系統自動建立了字首長度為767的字首索引;

5191bc643f543324db32581afa0b5567c14a0af5

看看大小: 8992k

0f50d03db66feb32ceba80cc478dc16b929ba800

嘗試在TEXT和BLOB的欄位上直接建立索引

mysql> alter table test_prefix_ind add key(text_str);

ERROR 1170 (42000): BLOB/TEXT column 'text_str' used in key specification without a key length

mysql> alter table test_prefix_ind add key(blob_str);;

ERROR 1170 (42000): BLOB/TEXT column 'blob_str' used in key specification without a key length複製程式碼

在TEXT和BLOB欄位上建立索引,必須指定字首長度。

alter table test_prefix_ind add key(text_str(30));;複製程式碼

看看大小,528k(9520-8992), 遠遠小於LONG_STR的8992k.

5ddc3d1e1f9a779ce3b6d496c578e7de0f0e834c

alter table test_prefix_ind add key(blob_str(30));;複製程式碼

看看大小,544k(10064-9520)。

fcb60da8d86f7de9acf48cb7aea0e81783870396

看看幾個表的字首長度和大小。字首長度顯著降低了索引的大小。

8f8aa9edd198219e42db5c3422aa35a521162984

看看查詢是否能正常進行:

184ad0e01ec08b4d86b625dbb72d3ded00ff757f

可以使用上索引。

字首索引長度的選擇

對於一個可能挺長的欄位,怎麼判斷合適的字首索引呢?

簡單做法:

Select count(distinct substr(long_str,1,5))/count(*) from test_prefix_ind;複製程式碼

炫一點的寫法,通過一些小技巧,可以在同一個SQL裡遍歷多個值,同時檢視多個值的選擇度。

select R,count(distinct substr(long_str,1,R))/count(*)

from

(SELECT @rownum:=ceil(@rownum*1.4) AS  R

 FROM (SELECT @rownum:=1) r,test_prefix_ind limit 1,10

 ) R,test_prefix_ind T

 group by R;;複製程式碼

44c529cbd56f92d6c97b0c8d6dd96e5e40bebe80

對於這個表,由於資料是隨機的,所以,前5位已經足夠好。

我們建立一個字首長度為5的字首索引。

alter table test_prefix_ind add key(long_str(5));複製程式碼

看看大小,僅僅258k(10320-10064),遠低於最早建立的8992k

c01f71dce86a9a91bc5012451a9bd28a3ec5eeff

測試一下效能,有字首索引時:

29050a558b3023b0abf0d3671b024b29c4f03fab

刪除索引後,效能差距很明顯:

f4298e7bd2799bde6c8d725f4ec2a3421ec3df1b

Oracle的類似實現

從前面的做法中,我們可以發現,字首索引本質上就是把欄位的前N位作為索引,這個看起來,很像Oracle的函式索引。類似於:

Create index index_name on table_name(substr(column_name,1,<length>) );複製程式碼

對於Oracle的函式索引,我們一個比較深的印象就是,where條件必須和函式索引裡的表示式一致,才能利用上函式索引。但既然MySQL可以用字首索引,作為老前輩的Oracle, 似乎應該也能實現才對。

我們來看看,在Oracle裡面,是否能夠實現同樣的功能。

建立表格:

Create table test_substr as

select object_id,object_name||dbms_random.string('x',dbms_random.value(1,1000) as object_name,created from all_objects ,

(select * from dual connect by level < 100)

where rownum < 10000;複製程式碼

建立substr的函式索引:

Create index test_substr_inx on test_substr(substr(object_name,1,5));複製程式碼

看看執行計劃:

ca4af3e20da82cfff9b8e2b6593a4f8d46f3d0f9

神奇的事情發生了,的確走了索引,Oracle也支援字首索引~~

我們可以看到,找謂詞中,增加了一個原來語句中沒有的東西:

47274310272193667855e7f110a459966db76a10

換成繫結變數看看:

2c512d1487ca7cc095183cc81d4eea9304fe4f4c

可以看到,謂詞中變成了:

083c2b39807b12230ec028a5e27b5d1e243c4a46

為什麼多了這個東西?因為,從邏輯上來說:

select * from test_substr where object_name=:a;複製程式碼

select * from test_substr where object_name=:a and substr(object_name,1,5)=substr(:a,1,5);複製程式碼

是百分百等價的。Oracle相當於自動做了語義上的優化。

有興趣的,可以做個10053。Oracle內部實際進行執行計劃解析的,就是這樣一個SQL。

SELECT * FROM TEST_SUBSTR WHERE OBJECT_NAME=:A AND SUBSTR(OBJECT_NAME,1,5)=SUBSTR(:A,1,5);複製程式碼

看看如果建立普通索引,空間佔用是多少。

Create index test_substr_inx2 on test_substr(object_name);複製程式碼

311f2ed90b53239ddf124fde6e2b66115a3cee87

大小分別是7M256K.

但Oracle僅止於此嗎?我們在來試試看另一個SQL, 這次,我們在條件上也使用substr,但是長度不為5。

603b53cb0ab37247950ea7a2cb6ba586e00dfaa7

果然還是可以的。因為邏輯上來說

select * from test_substr

 where substr(object_name,1,<N>)=:a;複製程式碼

在N>=5的時候,

select * from test_substr

where substr(object_name,1,<N>)=:a and substr(object_name,1,5)=substr(:a,1,5);複製程式碼

還是等價的。所以優化器還是可以繼續加一個謂詞。

當然,如果把WHERE條件中substr換成小於5的值,就不再能用得上索引。因為無法直接換為等價的、又帶有substr(object_name,1,5)的語句。

Oracle時間、數字上的字首索引

僅僅就這樣嗎?除了字元型別之外,數字型別和時間型別是否也支援?

我們再看看。

在剛才的表的基礎上,建立時間型別上的trunc函式索引。

Create index test_trunc_date_inx on test_substr(trunc(created));複製程式碼

看看執行計劃:

e963270c93485619c4283d22099d9730a28898ed

沒問題,還是可以的。

建立數字型別上的trunc函式索引:

create index test_trunc_number on TEST_SUBSTR(trunc(object_id));複製程式碼

b204c297a755c992c92d60974e163c3bdf90fee4

實際上,問題的關鍵在於等價與優化器的內部改寫。

我們最後再看另一個例子。

建另一個表,相當欄位長度最長為5。

create table test_scale (object_name varchar2(5));

insert into test_scale select substr(object_name,1,5) from all_objects;

create index test_scale_str_inx in test_scale(object_name);複製程式碼

來看看這個語句的執行效果

select * from  test_scale where object_name = 'DBA_TABLES';複製程式碼

655236aad640716e53139f62c12fbb67dd2e21cd

神奇的事情再次發生,autotrace中db block gets/consistent gets都為0,這代表資料庫根本就沒去訪問表。

原因很簡單,‘DBA_TABLES’這個值長度大於5, 超出了表定義中的varchar2(5)了。object_name = ‘DBA_TABLES’就等價於恆否的條件了。這個,在10053裡也找不到,但的確存在。


原文連結


相關文章