為什麼要進行SQL優化
為什麼要進行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樹本身就是一個排好序的結構，最左邊必然是最小的，最最右邊必然是最大的：
只需要根據一定的規則遍歷出來就行了。
後面小編會分享更多運維乾貨，感興趣的朋友走一波關注哩~
閱讀更多 智能運維小講堂 的文章
