聚簇索引、非聚簇索引、回表

• 聚簇索引：將數據存儲與索引放到了一塊，找到索引也就找到了數據

• 非聚簇索引：將數據存儲於索引分開結構，索引結構的葉子節點指向了數據的對應行，myisam經過key_buffer把索引先緩存到內存中，當須要訪問數據時（經過索引訪問數據），在內存中直接搜索索引，而後經過索引找到磁盤相應數據，這也就是爲何索引不在key buffer命中時，速度慢的緣由

澄清一個概念：innodb中，在聚簇索引之上建立的索引稱之爲輔助索引，輔助索引訪問數據老是須要二次查找，非聚簇索引都是輔助索引，像複合索引、前綴索引、惟一索引，輔助索引葉子節點存儲的再也不是行的物理位置，而是主鍵值

什麼時候使用聚簇索引與非聚簇索引

cluster.png

聚簇索引具備惟一性

因爲聚簇索引是將數據跟索引結構放到一塊，所以一個表僅有一個聚簇索引

一個誤區：把主鍵自動設爲聚簇索引

聚簇索引默認是主鍵，若是表中沒有定義主鍵，InnoDB 會選擇一個惟一的非空索引代替。若是沒有這樣的索引，InnoDB 會隱式定義一個主鍵來做爲聚簇索引。InnoDB 只彙集在同一個頁面中的記錄。包含相鄰健值的頁面可能相距甚遠。若是你已經設置了主鍵爲聚簇索引，必須先刪除主鍵，而後添加咱們想要的聚簇索引，最後恢復設置主鍵便可。

此時其餘索引只能被定義爲非聚簇索引。這個是最大的誤區。有的主鍵仍是無心義的自動增量字段，那樣的話Clustered index對效率的幫助，徹底被浪費了。

剛纔說到了，聚簇索引性能最好並且具備惟一性，因此很是珍貴，必須慎重設置。通常要根據這個表最經常使用的SQL查詢方式來進行選擇，某個字段做爲聚簇索引，或組合聚簇索引，這個要看實際狀況。

記住咱們的最終目的就是在相同結果集狀況下，儘量減小邏輯IO。

結合圖再仔細點看

image

image

1. InnoDB使用的是聚簇索引，將主鍵組織到一棵B+樹中，而行數據就儲存在葉子節點上，若使用"where id = 14"這樣的條件查找主鍵，則按照B+樹的檢索算法便可查找到對應的葉節點，以後得到行數據。

2. 若對Name列進行條件搜索，則須要兩個步驟：第一步在輔助索引B+樹中檢索Name，到達其葉子節點獲取對應的主鍵。第二步使用主鍵在主索引B+樹種再執行一次B+樹檢索操做，最終到達葉子節點便可獲取整行數據。（重點在於經過其餘鍵須要創建輔助索引）

MyISM使用的是非聚簇索引，非聚簇索引的兩棵B+樹看上去沒什麼不一樣，節點的結構徹底一致只是存儲的內容不一樣而已，主鍵索引B+樹的節點存儲了主鍵，輔助鍵索引B+樹存儲了輔助鍵。表數據存儲在獨立的地方，這兩顆B+樹的葉子節點都使用一個地址指向真正的表數據，對於表數據來講，這兩個鍵沒有任何差異。因爲索引樹是獨立的，經過輔助鍵檢索無需訪問主鍵的索引樹。

聚簇索引的優點

看上去聚簇索引的效率明顯要低於非聚簇索引，由於每次使用輔助索引檢索都要通過兩次B+樹查找，這不是畫蛇添足嗎？聚簇索引的優點在哪？

1. 因爲行數據和葉子節點存儲在一塊兒，同一頁中會有多條行數據，訪問同一數據頁不一樣行記錄時，已經把頁加載到了Buffer中，再次訪問的時候，會在內存中完成訪問，沒必要訪問磁盤。這樣主鍵和行數據是一塊兒被載入內存的，找到葉子節點就能夠馬上將行數據返回了，若是按照主鍵Id來組織數據，得到數據更快。

2. 輔助索引使用主鍵做爲"指針"而不是使用地址值做爲指針的好處是，減小了當出現行移動或者數據頁分裂時輔助索引的維護工做，使用主鍵值看成指針會讓輔助索引佔用更多的空間，換來的好處是InnoDB在移動行時無須更新輔助索引中的這個"指針"。也就是說行的位置（實現中經過16K的Page來定位）會隨着數據庫裏數據的修改而發生變化（前面的B+樹節點分裂以及Page的分裂），使用聚簇索引就能夠保證無論這個主鍵B+樹的節點如何變化，輔助索引樹都不受影響。

3. 聚簇索引適合用在排序的場合，非聚簇索引不適合

4. 取出必定範圍數據的時候，使用用聚簇索引

5. 二級索引須要兩次索引查找，而不是一次才能取到數據，由於存儲引擎第一次須要經過二級索引找到索引的葉子節點，從而找到數據的主鍵，而後在聚簇索引中用主鍵再次查找索引，再找到數據

6. 能夠把相關數據保存在一塊兒。例如實現電子郵箱時，能夠根據用戶 ID 來彙集數據，這樣只須要從磁盤讀取少數的數據頁就能獲取某個用戶的所有郵件。若是沒有使用聚簇索引，則每封郵件均可能致使一次磁盤 I/O。

聚簇索引的劣勢

1. 維護索引很昂貴，特別是插入新行或者主鍵被更新導至要分頁(page split)的時候。建議在大量插入新行後，選在負載較低的時間段，經過OPTIMIZE TABLE優化表，由於必須被移動的行數據可能形成碎片。使用獨享表空間能夠弱化碎片

2. 表由於使用UUId（隨機ID）做爲主鍵，使數據存儲稀疏，這就會出現聚簇索引有可能有比全表掃面更慢，

image

因此建議使用int的auto_increment做爲主鍵

image

主鍵的值是順序的，因此 InnoDB 把每一條記錄都存儲在上一條記錄的後面。當達到頁的最大填充因子時（InnoDB 默認的最大填充因子是頁大小的 15/16，留出部分空間用於之後修改），下一條記錄就會寫入新的頁中。一旦數據按照這種順序的方式加載，主鍵頁就會近似於被順序的記錄填滿（二級索引頁多是不同的）

3. 若是主鍵比較大的話，那輔助索引將會變的更大，由於輔助索引的葉子存儲的是主鍵值；過長的主鍵值，會致使非葉子節點佔用佔用更多的物理空間

爲何主鍵一般建議使用自增id

聚簇索引的數據的物理存放順序與索引順序是一致的，即：只要索引是相鄰的，那麼對應的數據必定也是相鄰地存放在磁盤上的。若是主鍵不是自增id，那麼能夠想 象，它會幹些什麼，不斷地調整數據的物理地址、分頁，固然也有其餘一些措施來減小這些操做，但卻沒法完全避免。但，若是是自增的，那就簡單了，它只須要一 頁一頁地寫，索引結構相對緊湊，磁盤碎片少，效率也高。

由於MyISAM的主索引並不是聚簇索引，那麼他的數據的物理地址必然是凌亂的，拿到這些物理地址，按照合適的算法進行I/O讀取，因而開始不停的尋道不停的旋轉。聚簇索引則只需一次I/O。（強烈的對比）

不過，若是涉及到大數據量的排序、全表掃描、count之類的操做的話，仍是MyISAM佔優點些，由於索引所佔空間小，這些操做是須要在內存中完成的。

mysql中聚簇索引的設定

聚簇索引默認是主鍵，若是表中沒有定義主鍵，InnoDB 會選擇一個惟一的非空索引代替。若是沒有這樣的索引，InnoDB 會隱式定義一個主鍵來做爲聚簇索引。InnoDB 只彙集在同一個頁面中的記錄。包含相鄰健值的頁面可能相距甚遠。

 

回表：

通俗的講就是，若是索引的列在 select 所需得到的列中（由於在 mysql 中索引是根據索引列的值進行排序的，因此索引節點中存在該列中的部分值）或者根據一次索

 

根據這個概念，當你使用 Explain 執行查詢計劃時，當結果中 Extra 出現了 using index、using where、using index condition 等你就認爲使用了過濾條件，使用了索引，SQL 優化的還不錯。這實際上是一種錯誤的認識。

由於，使用了索引並不表明查詢就最優。從 using index condition、using index & using where 等能夠看出，這條 SQL 語句實際上是進行了回表的。

還有些時候，你查看 Explain 執行計劃後，發現明明走了索引，爲何仍是慢？這裏面可能就是存在回表了。

 

再例如，雖然只查詢索引裏的列，可是須要回表過濾掉其餘行。

怎麼避免回表？

• 將須要的字段放在索引中去。查詢的時候就能避免回表。

可是不要刻意去避免回表，那樣代價太了。也不是將全部的字段都放在全部中。