偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

再聊 MySQL 聚簇索引

數(shù)據(jù)庫 MySQL
聚簇索引英文是 Clustered Index,有時候小伙伴們可能也會看到有人將之稱為聚集索引等,與之相對的是非聚簇索引或者二級索引。

為什么是再次理解呢?因為松哥之前寫過相關的文章介紹過聚簇索引,但是感覺還不夠,因此今天想再來和小伙伴們聊一聊這個話題。

一. 什么是聚簇索引

數(shù)據(jù)庫的索引從不同的角度可以劃分成不同的類型,聚簇索引便是其中一種。

聚簇索引英文是 Clustered Index,有時候小伙伴們可能也會看到有人將之稱為聚集索引等,與之相對的是非聚簇索引或者二級索引。

聚簇索引并不是一種單獨的索引類型,而是一種數(shù)據(jù)的存儲方式。在 MySQL 的 InnoDB 存儲引擎中,所謂的聚簇索引實際上就是在同一個 B+Tree 中保存了索引和數(shù)據(jù)行:此時,數(shù)據(jù)放在葉子結點中,聚簇聚簇,意思就是說數(shù)據(jù)行和對應的鍵值緊湊的存在一起。

假設我有如下數(shù)據(jù):

id(主鍵)

username

age

address

gender

1

ab

99

深圳


2

ac

98

廣州


3

af

88

北京


4

bc

80

上海


5

bg

85

重慶


6

bw

95

天津


7

bw

99

???br>


8

cc

92

武漢


9

ck

90

深圳


10

cx

93

深圳


那么它的聚簇索引大概就是這個樣子:

圖片

那么大家可以看到,葉子上既有主鍵值(索引)又有數(shù)據(jù)行,節(jié)點上則只有主鍵值(索引)。

小伙伴們想想,MySQL 表中的數(shù)據(jù)在磁盤中只可能保存一份,不可能保存兩份,所以,在一個表中,聚簇索引只可能有一個,不可能有多個。

二. 聚簇索引和主鍵

有的小伙伴搞不清楚這兩者之間的關系,甚至將兩者劃等號,這是一個巨大的誤區(qū)。

在有的數(shù)據(jù)庫中,支持開發(fā)者自由的選擇使用哪一個索引作為聚簇索引,但是 MySQL 中是不支持這個特性的。

在 MySQL 中,如果表本身就有設置主鍵,那么主鍵就是聚簇索引;如果表本身沒有設置主鍵,則會選擇表中的一個唯一且非空的索引來作為聚簇索引;如果表中連唯一非空的索引都沒有,那么就會自動選擇表中的隱式主鍵來作為聚簇索引。關于 MySQL 中表的隱式主鍵,松哥會在將來的文章中和大家介紹。

不過一般來說,還是建議大家自己來為表設置主鍵,因為隱式主鍵是自增的,自增的都會存在一個問題:在自增值上會存在非常高的鎖競爭問題,主鍵的上界會稱為熱點數(shù)據(jù),因為所有的插入操作都要主鍵自增,又不能重復,所以會發(fā)生鎖競爭進而導致性能降低。

根據(jù)上面的介紹,我們可以總結出 MySQL 中聚簇索引和主鍵索引的關系如下:

  1. 聚簇索引不一定是主鍵索引。
  2. 主鍵索引一定是聚簇索引。

三. 聚簇索引優(yōu)缺點

先來說優(yōu)點:

  1. 相互關聯(lián)的數(shù)據(jù)我們可以將之保存在一起。例如有一個用戶訂單表,我們可以根據(jù) 用戶 ID + 訂單 ID 來聚集所有數(shù)據(jù),用戶 ID 可能會重復,訂單 ID 則不會重復,這樣我們就能夠?qū)⒁粋€用戶相關的訂單數(shù)據(jù)都保存在一起,如果需要查詢一個用戶的所有訂單,就會非???,只需要少量的磁盤 IO 就可以做到。
  2. 不需要回表,因此數(shù)據(jù)訪問速度更快。在聚簇索引中,索引和數(shù)據(jù)都在同一棵 B+Tree 上,因此從聚簇索引中獲取到的數(shù)據(jù)比從非聚簇索引上獲取數(shù)據(jù)更快(非聚簇索引需要回表)。
  3. 對于第一點的案例,如果我們想根據(jù)用戶 ID 查詢到這個用戶所有的訂單 ID,那么此時都不用去到葉子結點了,因為支節(jié)點上就有我們需要的數(shù)據(jù),所以直接利用覆蓋索引的特性,就可以讀取到需要的數(shù)據(jù)。

這些就是聚簇索引一些常見的優(yōu)點,我們在日常的表設計中,其實應該充分利用好這些優(yōu)點。

再來看看缺點:

  1. 小伙伴們發(fā)現(xiàn),前面我們說的聚簇索引的優(yōu)勢主要是聚簇索引減少了 IO 次數(shù),從而提高了數(shù)據(jù)庫的性能,但是有的 IO 密集型應用,可能直接上一個足夠大的內(nèi)存,把數(shù)據(jù)都讀取到內(nèi)存中操作,此時聚簇索引就沒有啥優(yōu)勢了。
  2. 隨機主鍵會導致頁分裂問題,主鍵順序插入的話,相對來說效率會高一些,因為在 B+Tree 中只需要不斷往后面追加即可;但是主鍵如果是非順序插入的話,效率就會低很多,因為可能會涉及到頁分裂問題。以上面那張圖為例,假設每個節(jié)點可以保存三條數(shù)據(jù),現(xiàn)在我們要插入一個主鍵是 4.5 的記錄,那么就需要把主鍵為 5 的值往后移動,進而導致主鍵為 8 的節(jié)點也要往后移動。頁分裂會導致數(shù)據(jù)插入效率降低并且占用更多的存儲空間。
  3. 非聚簇索引(二級索引)查詢的時候需要回表。因為一個索引就是一棵索引樹,數(shù)據(jù)都在聚簇索引上,所以如果使用非聚簇索引進行搜索,非聚簇索引的葉子上存儲的是主鍵值,先找到主鍵值,然后拿著主鍵值再來聚簇索引上搜索,這樣一共就查詢了兩棵索引樹,這就是回表。

四. 最佳實踐

看了上面的介紹,相信小伙伴已經(jīng)了解了,在使用聚簇索引的時候,主鍵最好不要使用 UUID 這種隨機字符串,使用 UUID 隨機字符串至少存在兩方面的問題:

  1. 插入效率低,因為插入可能會導致頁分裂,這個前面已經(jīng)說過了。
  2. UUID 字符串所占用的存儲空間遠遠大于一個 bigint,如果使用 UUID 來做主鍵,意味著在二級索引中,一個葉子結點能夠存儲的主鍵值就非常有限,進而可能會導致樹增高,搜索時候 IO 次數(shù)增多,性能下降。

所以相對來說,主鍵自增會優(yōu)于 UUID。那么主鍵自增就是最完美的方案了嗎?很多小伙伴可能也聽說過一句話:沒有銀彈!所以,主鍵自增其實也有問題,具體什么問題,我們下便文章繼續(xù)。

責任編輯:武曉燕 來源: 江南一點雨
相關推薦

2025-05-06 08:55:00

2025-02-28 10:31:50

2010-07-14 15:04:53

SQL Sever索引

2010-09-27 11:24:37

SQL聚簇索引

2025-04-28 07:10:46

聚簇非聚簇索引

2023-06-12 08:38:23

聚簇索引排序非聚簇索引

2024-05-24 09:28:22

2010-04-21 13:43:31

Oracle聚簇索引

2022-06-13 07:36:06

MySQLInnoDB索引

2010-05-31 13:57:49

2010-04-12 16:50:47

Oracle索引聚簇表

2010-04-12 17:00:37

Oracle索引聚簇表

2022-03-25 10:38:40

索引MySQL數(shù)據(jù)庫

2023-05-23 22:19:04

索引MySQL優(yōu)化

2010-04-01 17:14:04

Oracle索引

2021-07-02 09:45:29

MySQL InnoDB數(shù)據(jù)

2020-02-14 18:10:40

MySQL索引數(shù)據(jù)庫

2023-06-05 08:07:34

聚集索引存儲數(shù)據(jù)

2024-03-25 13:02:00

MySQL索引主鍵

2023-04-26 07:40:34

MySQL索引類型存儲
點贊
收藏

51CTO技術棧公眾號