MySQL優(yōu)化中B樹(shù)索引知識(shí)點(diǎn)總結(jié)

更新時(shí)間：2019年02月21日 16:24:30 投稿：laozhang

在本文里我們給大家整理了關(guān)于MySQL優(yōu)化中B樹(shù)索引的相關(guān)知識(shí)點(diǎn)內(nèi)容，需要的朋友們可以學(xué)習(xí)下。

為什么要進(jìn)行SQL優(yōu)化呢？很顯然，當(dāng)我們?nèi)?xiě)sql語(yǔ)句時(shí)：

1會(huì)發(fā)現(xiàn)性能低
2.執(zhí)行時(shí)間太長(zhǎng)，
3.或等待時(shí)間太長(zhǎng)
4.sql語(yǔ)句欠佳，以及我們索引失效
5.服務(wù)器參數(shù)設(shè)置不合理

SQL語(yǔ)句執(zhí)行過(guò)程分析

1.編寫(xiě)過(guò)程：

編寫(xiě)過(guò)程就是我們平常寫(xiě)sql語(yǔ)句的過(guò)程，也可以理解為編寫(xiě)順序，以下就是我們編寫(xiě)順序：

select from join on where 條件 group by 分組 having過(guò)濾組 order by排序 limit限制查詢(xún)個(gè)數(shù)

我們雖然是這樣去寫(xiě)的，但是它mysql的引擎去解析時(shí)，并不是依照我們以上編寫(xiě)的這樣的順序；

它并不是先解析select 而是先解析from，也就說(shuō)，我們的解析過(guò)程跟編寫(xiě)過(guò)程是不一致的，所以我們看下發(fā)的解析順序

2.解析過(guò)程：

from on join where group by having select order by limit

以上就是mysql的解析過(guò)程，我們發(fā)現(xiàn)，跟我們編寫(xiě)的過(guò)程完全不一致！

索引

什么是索引(index)？簡(jiǎn)單的來(lái)講就是書(shū)的目錄；

比如說(shuō)我現(xiàn)在要通過(guò)字典來(lái)查“王”這個(gè)字，如果你在沒(méi)有目錄的情況下去找“王”這個(gè)字，你就需要把這個(gè)字典從頭到尾的翻一遍，如果有一千頁(yè)，你就必須一頁(yè)一頁(yè)的去翻，直到找到為止；

索引就相當(dāng)于目錄，查這個(gè)“王”之前先去翻看目錄，發(fā)現(xiàn)“W”在300頁(yè)，因?yàn)橥跏鬃帜甘恰癢”，我們直接去在300頁(yè)中找，這樣找起來(lái)就非常快；

索引在數(shù)據(jù)庫(kù)中是關(guān)鍵字insex,用官方的定義的意思來(lái)說(shuō)，索引就是幫助MySQL快速高效的獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)；

索引是一個(gè)數(shù)據(jù)結(jié)構(gòu)，它是一個(gè)為了高效查詢(xún)數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)；

那它到底是什么數(shù)據(jù)結(jié)構(gòu)呢？

其實(shí)它就是一個(gè)樹(shù)，我們用的比較多的就是B樹(shù)、Hash樹(shù)，在MySQL里面，用的就是B樹(shù)索引；

B樹(shù)索引

首先我畫(huà)一個(gè)圖，假裝這個(gè)是數(shù)據(jù)表，并且給age列加一個(gè)索引：

就把這個(gè)索引當(dāng)成一個(gè)目錄，也就是age為50的，就指向第一行，age為33的，指向第五行；

下面我會(huì)將B樹(shù)索引畫(huà)出來(lái)，看看到底是怎么索引了：

我們給age加了索引列后，它就會(huì)像樹(shù)一樣，把小的放到左邊，把大的放到右邊，第一列為50，比50小的在左邊，23，比23小的繼續(xù)向左排列，

33比23大，就向左排列20比22小就在22后面繼續(xù)向左排列，以此類(lèi)推！

比如我們現(xiàn)在需要查33:

select * From 表名 where age = 33;

不加索引的話(huà)，就會(huì)從50開(kāi)始查，50不是 23，不是22不是....，不加索引就一個(gè)個(gè)去找；

如果加索引的話(huà)，找33，發(fā)現(xiàn)33比50小，第一次，再去找23，第二次，33比23大，第三次，僅需三次就查到了：

索引的弊端

1.索引本身很占空間，可以存放在內(nèi)存/硬盤(pán)（通常）

2.索引不是所有情況均可適用比如：少量數(shù)據(jù)、頻繁更新的字段（如果數(shù)據(jù)表中的某一列經(jīng)常會(huì)發(fā)生改變，那么這一列就不適合做索引）

3.索引確實(shí)可以提高查詢(xún)效率，但是同時(shí)會(huì)降低增刪改的效率，比如：

我們沒(méi)有索引，你改44，改成45，很好改，直接改就行了，如果你有索引，我不光要改表里面的44，我需要把B樹(shù)里面的44也要改：

有些人就覺(jué)得不劃算了，提升一個(gè)降低三個(gè)，這樣就很不劃算了，其實(shí)很劃算的！

因?yàn)槲覀兇蟛糠智闆r下都是在查詢(xún)，增刪改很少，因?yàn)椴樵?xún)影響性能很大的，所以非常有必要使用它

索引的優(yōu)勢(shì)

1.提高了查詢(xún)效率

客戶(hù)端到服務(wù)端，鏈接服務(wù)端是通過(guò)IO，通過(guò)輸入輸出流，所以說(shuō)，提高查詢(xún)效率就是降低了IO的使用率

2.降低CPU使用率

比如說(shuō)我sql里面有一個(gè)order by desc 根據(jù)年齡降序或升序，如果沒(méi)有索引，你需要把a(bǔ)ge全部拿出來(lái)全部排個(gè)序，但是如果有了索引，你就不需要排序了，B樹(shù)本身就是一個(gè)排好序的結(jié)構(gòu)，最左邊必然是最小的，最最右邊必然是最大的：