花1分鐘時(shí)間，了解聚集索引，非聚集索引，聯(lián)合索引，索引覆蓋。

舉例，業(yè)務(wù)場(chǎng)景，用戶表，表結(jié)構(gòu)為：

t_user(

uid primary key,

login_name unique,

passwd,

login_time,

age,

…

);

聚集索引(clustered index)：聚集索引決定數(shù)據(jù)在磁盤(pán)上的物理排序，一個(gè)表只能有一個(gè)聚集索引，一般用primary key來(lái)約束。

舉例：t_user場(chǎng)景中，uid上的索引。

非聚集索引(non-clustered index)：它并不決定數(shù)據(jù)在磁盤(pán)上的物理排序，索引上只包含被建立索引的數(shù)據(jù)，以及一個(gè)行定位符row-locator，這個(gè)行定位符，可以理解為一個(gè)聚集索引物理排序的指針，通過(guò)這個(gè)指針，可以找到行數(shù)據(jù)。

舉例，查找年輕MM的業(yè)務(wù)需求：

select uid from t_user where age > 18 and age  26;

age上建立的索引，就是非聚集索引。

聯(lián)合索引：多個(gè)字段上建立的索引，能夠加速?gòu)?fù)核查詢條件的檢索

舉例，登錄業(yè)務(wù)需求：

select uid, login_time from t_user where 

login_name=? and passwd=?

可以建立(login_name, passwd)的聯(lián)合索引。

聯(lián)合索引能夠滿足最左側(cè)查詢需求，例如(a, b, c)三列的聯(lián)合索引，能夠加速a | (a, b) | (a, b, c) 三組查詢需求。

這也就是為何不建立(passwd, login_name)這樣聯(lián)合索引的原因，業(yè)務(wù)上幾乎沒(méi)有passwd的單條件查詢需求，而有很多l(xiāng)ogin_name的單條件查詢需求。

提問(wèn)：

select uid, login_time from t_user where

passwd=? and login_name=?

能否命中(login_name, passwd)這個(gè)聯(lián)合索引？

回答：可以，最左側(cè)查詢需求，并不是指SQL語(yǔ)句的寫(xiě)法必須滿足索引的順序（這是很多朋友的誤解）

索引覆蓋：被查詢的列，數(shù)據(jù)能從索引中取得，而不用通過(guò)行定位符row-locator再到row上獲取，即“被查詢列要被所建的索引覆蓋”，這能夠加速查詢速度。

舉例，登錄業(yè)務(wù)需求：

select uid, login_time from t_user where

login_name=? and passwd=?

可以建立(login_name, passwd, login_time)的聯(lián)合索引，由于login_time已經(jīng)建立在索引中了，被查詢的uid和login_time就不用去row上獲取數(shù)據(jù)了，從而加速查詢。

末了多說(shuō)一句，登錄這個(gè)業(yè)務(wù)場(chǎng)景，login_name具備唯一性，建這個(gè)單列索引就好。

作業(yè)：

假設(shè)訂單有三種狀態(tài)：0已下單，1已支付，2已完成

業(yè)務(wù)需求，查詢未完成的訂單，哪個(gè)SQL更快呢？

select * from order where status!=2

select * from order where status=0 or status=1

select * from order where status IN (0,1)

select * from order where status=0

union

select * from order where stauts=1

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。