聚簇索引：（非索引類型逸尖，只是一種數(shù)據(jù)存儲(chǔ)方式） 表數(shù)據(jù)按照索引順序存儲(chǔ)避凝，葉子結(jié)點(diǎn)存儲(chǔ)了真實(shí)數(shù)據(jù)行社痛，一張表上面最多只能創(chuàng)建一個(gè)聚簇索引坠七。
如圖：葉子頁(yè)中包含了行的全部數(shù)據(jù)水醋，但是節(jié)點(diǎn)頁(yè)只包含了索引列。
其他非聚簇索引的結(jié)構(gòu)的彪置，葉子節(jié)點(diǎn)中仍然是索引節(jié)點(diǎn)拄踪，只不過(guò)是有指向其對(duì)應(yīng)數(shù)據(jù)塊的指針。
優(yōu)點(diǎn)：
- 可以把相關(guān)數(shù)據(jù)保存在一起拳魁，例如電子郵箱中惶桐，根據(jù)用戶ID來(lái)聚集數(shù)據(jù)，這樣就可以磁盤讀取少量的數(shù)據(jù)頁(yè)便可以讀取到某個(gè)用戶的全部郵件
- 數(shù)據(jù)訪問(wèn)更塊潘懊，聚簇索引將數(shù)據(jù)和索引保存在同一個(gè)B-Tree中姚糊，直接能從聚簇索引中獲取數(shù)據(jù)
缺點(diǎn)：
聚簇索引按照順序存儲(chǔ)且在葉子節(jié)點(diǎn)中存儲(chǔ)真實(shí)數(shù)據(jù)行會(huì)導(dǎo)致數(shù)據(jù)更新等操作比較麻煩
- 插入速度依賴于插入順序
- 更新聚簇索引代價(jià)很高
- 全表掃描很慢
如下表例子：
| id | name | gender | total_score | city |
|---|---|---|---|---|
| 1 | Jolly | Female | 500 | London |
| 2 | Jon | Male | 545 | Manchester |
| 3 | Sara | Female | 600 | Leeds |
| 4 | Laura | Female | 400 | Liverpool |
| 5 | Alan | Male | 500 | London |
| 6 | Kate | Female | 500 | Liverpool |
| 7 | Joseph | Male | 643 | London |
| 8 | Mice | Male | 543 | Liverpool |
| 9 | Wise | Male | 499 | Manchester |
| 10 | Elis | Female | 400 | Leeds |
Sqlserver中可以選擇索引作為聚簇索引，比如
CREATE CLUSTERED INDEX IX_tblStudent_Gender_Score ON student(gender ASC, total_score DESC)
根據(jù)用戶的性別(gender)和總得分(total_score)創(chuàng)建聚簇索引授舟，找所有記錄的結(jié)果便會(huì)是:
| id | name | gender | total_score | city |
|---|---|---|---|---|
| 3 | Sara | Female | 600 | Leeds |
| 1 | Jolly | Female | 500 | London |
| 6 | Kate | Female | 500 | Liverpool |
| 4 | Laura | Female | 400 | Liverpool |
| 10 | Elis | Female | 400 | Leeds |
| 7 | Joseph | Male | 643 | London |
| 2 | Jon | Male | 545 | Manchester |
| 8 | Mice | Male | 543 | Liverpool |
| 5 | Alan | Male | 500 | London |
| 9 | Wise | Male | 499 | Manchester |
mysql 中并不支持自選索引作為聚簇索引救恨，對(duì)于InnoDB，一般通過(guò)主鍵聚集數(shù)據(jù)释树，如果沒有主鍵列肠槽，便會(huì)選擇一個(gè)唯一的非空索引代替，如果沒有這樣的索引奢啥，InnoDB會(huì)隱式定義一個(gè)主鍵來(lái)作為聚簇索引秸仙。
覆蓋索引： 一個(gè)索引包含所有需要查詢的字段的值，我們稱為覆蓋索引桩盲。
需要查詢字段的值寂纪，即覆蓋索引必須要存儲(chǔ)索引列的值。所以Mysql只能使用B-Tree索引做覆蓋索引赌结。
