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頁中找，這樣找起來就非常快；
索引在資料庫中是關鍵字insex , 用官方的定義的意思來說，索引就是幫助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樹本身就是一個排好序的結構 ，最左邊必然是最小的，最最右邊必然是最大的：
只需要根據一定的規則遍歷出來就行了。
今日感悟：
很多父母或者年輕人找工作細化追求一份“鐵飯碗”，
認為穩定最重要，
但在這個世界上，唯一不變的鐵律就是變化，
不管是公務員，還是國企，都只有靠能力，在崗位上才能站穩腳，
什麼是真正的鐵飯碗？
鐵飯碗絕不是在一個單位幹一輩子，
而是到了那兒，你都有飯吃，荒年餓不死手藝人，能力才是硬道理！