SQL優化 MySQL版 - B樹索引詳講

SQL優化 MySQL版  - -B樹索引詳講

做者：Stanley 羅昊

【轉載請註明出處和署名，謝謝！】

爲何要進行SQL優化呢？很顯然，當咱們去寫sql語句時：

1會發現性能低

2.執行時間太長，

3.或等待時間太長

4.sql語句欠佳，以及咱們索引失效

5.服務器參數設置不合理

SQL語句執行過程分析

1.編寫過程：

編寫過程就是咱們日常寫sql語句的過程，也能夠理解爲編寫順序，如下就是咱們編寫順序：

select from join on where 條件 group by 分組 having過濾組 order by排序 limit限制查詢個數

咱們雖然是這樣去寫的，可是它mysql的引擎去解析時，並非依照咱們以上編寫的這樣的順序；

它並不是先解析select 而是先解析from，也就說，咱們的解析過程跟編寫過程是不一致的，因此咱們看下發的解析順序

2.解析過程：

from on join where group by having select order by limit 

以上就是mysql的解析過程，咱們發現，跟咱們編寫的過程徹底不一致！

索引

什麼是索引(index)？簡單的來說就是書的目錄；

好比說我如今要經過字典來查「王」這個字，若是你在沒有目錄的狀況下去找「王」這個字，你就須要把這個字典從頭至尾的翻一遍，若是有一千頁，你就必須一頁一頁的去翻，直到找到爲止；

索引就至關於目錄，查這個「王」以前先去翻看目錄，發現「W」在300頁，由於王首字母是「W」，咱們直接去在300頁中找，這樣找起來就很是快；

索引在數據庫中是關鍵字index,用官方的定義的意思來講，索引就是幫助MySQL快速高效的獲取數據的數據結構；

索引是一個數據結構，它是一個爲了高效查詢數據的數據結構；

那它究竟是什麼數據結構呢？

其實它就是一個樹，咱們用的比較多的就是B樹、Hash樹，在MySQL裏面，用的就是B樹索引；

B樹索引

首先我畫一個圖，僞裝這個是數據表，而且給age列加一個索引：

就把這個索引當成一個目錄，也就是age爲50的，就指向第一行，age爲33的，指向第五行；

下面我會將B樹索引畫出來，看看究竟是怎麼索引了：

咱們給age加了索引列後，它就會像樹同樣，把小的放到左邊，把大的放到右邊，第一列爲50，比50小的在左邊，23，比23小的繼續向左排列，

33比23大，就向右邊排列20比22小就在22後面繼續向左排列，以此類推！

好比咱們如今須要查33:

select * From 表名 where age = 33;

不加索引的話，就會從50開始查，50不是 23，不是22不是....，不加索引就一個個去找；

若是加索引的話，找33，發現33比50小，第一次，再去找23，第二次，33比23大，第三次，僅需三次就查到了：

索引的弊端

1.索引自己很佔空間，能夠存放在內存/硬盤（一般）

2.索引不是全部狀況都可適用好比：少許數據、頻繁更新的字段（若是數據表中的某一列常常會發生改變，那麼這一列就不適合作索引）

3.索引確實能夠提升查詢效率，可是同時會下降增刪改的效率，好比：

咱們沒有索引，你改44，改爲45，很好改，直接改就好了，若是你有索引，我不光要改表裏面的44，我須要把B樹裏面的44也要改：

有些人就以爲不划算了，提高一個下降三個，這樣就很不划算了，其實很划算的！

由於咱們大部分狀況下都是在查詢，增刪改不多，由於查詢影響性能很大的，因此很是有必要使用它

索引的優點

1.提升了查詢效率

客戶端到服務端，連接服務端是經過IO，經過輸入輸出流，因此說，提升查詢效率就是下降了IO的使用率

2.下降CPU使用率

好比說我sql裏面有一個order by desc 根據年齡降序或升序，若是沒有索引，你須要把age所有拿出來所有排個序，可是若是有了索引，你就不須要排序了，B樹自己就是一個排好序的結構，最左邊必然是最小的，最最右邊必然是最大的：

只須要根據必定的規則遍歷出來就好了。

今日感悟：

不少父母或者年輕人找工做細化追求一份「鐵飯碗」，

認爲穩定最重要，

但在這個世界上，惟一不變的鐵律就是變化，

不論是公務員，仍是國企，都只有靠能力，在崗位上才能站穩腳，

什麼是真正的鐵飯碗？

鐵飯碗毫不是在一個單位幹一生，

而是到了那兒，你都有飯吃，荒年餓不死手藝人，能力纔是硬道理！