為什么要進行SQL優(yōu)化呢？很顯然，當我們?nèi)憇ql語句時：

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

SQL語句執(zhí)行過程分析

1.編寫過程：

編寫過程就是我們平常寫sql語句的過程，也可以理解為編寫順序，以下就是我們編寫順序：

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

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

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

2.解析過程：

from on join where group by having select order by limit 

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

索引

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

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

索引就相當于目錄，查這個“王”之前先去翻看目錄，發(fā)現(xiàn)“W”在300頁，因為王首字母是“W”，我們直接去在300頁中找，這樣找起來就非?？?；

索引在數(shù)據(jù)庫中是關鍵字insex,用官方的定義的意思來說，索引就是幫助MySQL快速高效的獲取數(shù)據(jù)的數(shù)據(jù)結構；

索引是一個數(shù)據(jù)結構，它是一個為了高效查詢數(shù)據(jù)的數(shù)據(jù)結構；

那它到底是什么數(shù)據(jù)結構呢？

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

B樹索引

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

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

下面我會將B樹索引畫出來，看看到底是怎么索引了：

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

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

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

select * From 表名 where age = 33;

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

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

索引的弊端

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

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

3.索引確實可以提高查詢效率，但是同時會降低增刪改的效率，比如：

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

有些人就覺得不劃算了，提升一個降低三個，這樣就很不劃算了，其實很劃算的！

因為我們大部分情況下都是在查詢，增刪改很少，因為查詢影響性能很大的，所以非常有必要使用它

索引的優(yōu)勢

1.提高了查詢效率

客戶端到服務端，鏈接服務端是通過IO，通過輸入輸出流，所以說，提高查詢效率就是降低了IO的使用率

2.降低CPU使用率

比如說我sql里面有一個order by desc 根據(jù)年齡降序或升序，如果沒有索引，你需要把age全部拿出來全部排個序，但是如果有了索引，你就不需要排序了，B樹本身就是一個排好序的結構，最左邊必然是最小的，最最右邊必然是最大的：

只需要根據(jù)一定的規(guī)則遍歷出來就行了。

以上就是相關的B數(shù)索引的相關知識點，感謝大家的閱讀和對腳本之家的支持。

最新評論