MySQL中的全表掃描和索引樹掃描?的實例詳解
引言
在學習mysql時,我們經(jīng)常會使用explain來查看sql查詢的索引等優(yōu)化手段的使用情況。在使用explain時,我們可以觀察到,explain的輸出有一個很關鍵的列,它就是type屬性,type表示的是掃描方式,代表 MySQL 使用了哪種索引類型,不同的索引類型的查詢效率是不一樣的。
在type這一列,有如下一些可能的選項:
system:系統(tǒng)表,少量數(shù)據(jù),往往不需要進行磁盤IOconst:常量連接eq_ref:主鍵索引(primary key)或者非空唯一索引(unique not null)等值掃描ref:非主鍵非唯一索引等值掃描range:范圍掃描index:索引樹掃描ALL:全表掃描(full table scan)
在上面列出的7種選項中,前面五種我就不詳細講了,可以參考Mysql Explain之type詳解這篇文章。我當時對于前五種屬性是比較容易就理解了的,但是對于后面兩種即索引樹掃描和全表掃描我還是存在一些疑問。
索引樹掃描我們是比較熟悉的,它就是會遍歷聚簇索引樹,底層是一顆B+樹,葉子節(jié)點存儲了所有的實際行數(shù)據(jù)。其實,全表掃描也是掃描的聚簇索引樹,因為聚簇索引樹的葉子節(jié)點中存儲的就是實際數(shù)據(jù),只要掃描遍歷聚簇索引樹就可以得到全表的數(shù)據(jù)了。
那索引樹掃描和全表掃描究竟有什么區(qū)別呢?
以下將以一個實例來詳細分析這兩種掃描方式的區(qū)別。
實例
我們建立一張t_article表:
create table t_article(
t_article_id int primary key auto_increment,
t_title varchar(40),
);在我們創(chuàng)建的t_article表中,只有兩個字段,一個是主鍵t_article_id,另一個是普通字段t_title。
我們知道,InnoDB會將聚簇索引默認建立在主鍵上,而聚簇索引樹中的葉子節(jié)點就存儲了整張表的行數(shù)據(jù)。
接著,我們分別設計兩個sql查詢case:
走主鍵索引
explain SELECT t_article_id FROM t_article;
走全表掃描:
explain SELECT t_title FROM t_article;
以上兩個查詢都沒有where查詢,按理來說底層的sql執(zhí)行情況應該是差不多的。
結(jié)果分析
我們可以來看看上面兩種查詢的結(jié)果,在查詢時使用explain語句輸出sql執(zhí)行的詳細信息。
1.走索引掃描
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | t_article | index | PRIMARY | 4 | 2 | 100 | Using index |
2.走全表掃描
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | t_article | ALL |
從以上兩個查詢結(jié)果中我們可以發(fā)現(xiàn),走主鍵索引的查詢和走全表的查詢是不一樣的。我們前面也提到了,InnoDB的索引是使用B+樹來實現(xiàn)的,而主鍵索引中存儲了整張表的數(shù)據(jù),那全表掃描時其實也是掃描的主鍵索引。那為什么這兩種查詢會不一樣呢?按理來說都是查詢的主鍵索引,它們應該是一樣的。
其實,它們兩者是有一些細節(jié)區(qū)別的。
比如,第一個查詢,它的優(yōu)化手段是使用索引樹掃描,也就是type中顯示的index屬性,而且它還使用了覆蓋索引,即Extra列中的Using index屬性。之所以第一個查詢能夠使用這兩種優(yōu)化手段,其實是因為select查詢的結(jié)果列只包含主鍵,而主鍵的值是可以直接在遍歷聚簇索引樹時確定,也不需要回表查詢了。
對于第二個查詢,它也沒有使用where進行過濾,而且它的select結(jié)果列包含的是普通列,并不是主鍵或者其他索引列,所以它會走全表掃描。而全表掃描其實底層也是掃描的聚簇索引樹,也就是底層的B+樹。這種全表掃描與索引樹掃描有一個明顯區(qū)別,那就是,全表掃描不僅僅需要掃描索引列,還需要掃描每個索引列中指向的實際數(shù)據(jù),這里包含了所有的非索引列數(shù)據(jù)。
前面的分析可能還是有點生硬和難以理解,具體地,我們通過下面一張圖來更直觀地看一下:

從上面的圖我們可以看到,對于索引掃描來講,它只需要讀取葉子節(jié)點的所有key,也就是索引的鍵,而不需要讀取具體的data行數(shù)據(jù);而對于全表掃描來說,它無法僅僅通過讀取索引列獲得需要的數(shù)據(jù),還需要讀取具體的data數(shù)據(jù)才能獲取select中指定的非索引列的具體值。所以,全表掃描的效率相比于索引樹掃描相對較低一點,但是差距不是很大。
參考
【mysql】全表掃描過程 & 聚簇索引 區(qū)別和聯(lián)系
從數(shù)據(jù)頁的角度看 B+ 樹
到此這篇關于MySQL中的全表掃描和索引樹掃描 的文章就介紹到這了,更多相關mysql全表掃描和索引樹掃描 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
MySQL中的alter table命令的基本使用方法及提速優(yōu)化
這篇文章主要介紹了MySQL中的alter table命令的基本使用方法及提速優(yōu)化的方法,包括ALTER COLUMN的使用等等,需要的朋友可以參考下2015-11-11
mac安裝mysql數(shù)據(jù)庫及配置環(huán)境變量的圖文教程
本文主要介紹了mac安裝mysql數(shù)據(jù)庫及配置環(huán)境變量,文中通過圖文代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下2021-08-08
MySQL 配置文件 my.cnf / my.ini 區(qū)別解析
充分理解 MySQL 配置文件中各個變量的意義對我們有針對性的優(yōu)化 MySQL 數(shù)據(jù)庫性能有非常大的意義,這篇文章主要介紹了MySQL 配置文件 my.cnf / my.ini 區(qū)別,需要的朋友可以參考下2022-11-11
Windows下MySQL服務啟動常見的兩種方式(適配5.7和8.0)
本文主要介紹了Windows下MySQL服務啟動常見的兩種方式(適配5.7和8.0),文中通過圖文介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2024-07-07
IDEA配置連接MYSQL數(shù)據(jù)庫遇到Failed這個問題解決
這篇文章主要介紹了IDEA配置連接MYSQL數(shù)據(jù)庫遇到Failed這個問題解決,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2020-11-11
mysql查線上數(shù)據(jù)注意數(shù)據(jù)庫的隔離級別
數(shù)據(jù)庫的隔離級別關乎事務對其他并發(fā)事務的可見性及其對數(shù)據(jù)庫的影響,隔離級別的選擇決定了并發(fā)性能和數(shù)據(jù)一致性的平衡,SQL標準定義了四種隔離級別,每種級別都有不同的應用場景和防止并發(fā)問題的能力,感興趣的可以了解一下2024-10-10

