MySQL主要提供2種方式的索引：B-Tree（包括B+Tree）索引，Hash索引。
B-Tree的存儲方式是平衡二叉樹；
Hash索引的存儲方式是構建hash表。
B. MySql 索引（聚集索引，輔助索引，聯合索引，覆蓋索引..）
引入一個面試問題:
看完以下以後再回顧，會發現迎刃而解
Mysql 可以為每一張表設置 存儲引擎 這里我們只說 InnoDB 存儲引擎.
由於實際情況，數據頁只能按照一棵 B+樹 進行排序， 因此每張表只能擁有一個 聚集索引（即 主鍵）。
栗子：
每個葉子節點的索引行中包含了一個書簽（bookmark）. 該書簽是用來告訴 InnoDB存儲引擎哪裡可以找到該索引對應的數據行或者說 行數據！ 由於InnoDB存儲引擎表， 是按照主鍵來構建的， 所以 ，該書簽內其實包含或者說指向了 數據行所滲叢對應的聚集索引鍵
也就是說 輔助索引的 葉結點保存了 指向對應數據的 聚集索引， 可以通過該聚集索引 找到對應的數據行
輔助索引的存在並不影響數據在聚集索引中的組織，因為每張表上可以有多個輔助索引。
當通過輔助索引來尋找數據時，InnoDB 存儲引擎會遍歷輔助索引並通過葉級別的指針獲得指向主鍵索引(聚集索引)的主鍵，然後再通過聚集索引找到一個完整的數據行。
例如：
聚集索引輔助索引關系:
： 又叫做組合索引 ， 輔助索引的一種 ， 和普通創建索引的方仔賣式一樣，不同的是 可以同時添加多列來作為索引項;
從本質上來說，聯合索引也是一課B+樹
個人理解： 所謂最左原則， 是因為 存儲引擎構建組合索引時 是根據最左邊的那一列索引項進行排序的 ，所以使用組合索引，必須滿足 條件中必須存在 最左邊那一列的索引項，這樣 才可以找到對應的索引，繼而 去尋找對應的數據
： 又叫做 索引覆蓋，InnoDB中支持覆蓋索引，即 從輔助索引中就可以得到查詢的記錄，而不需要查詢聚集索引中的記錄。
比如 這里沒有根據最念喊逗左原則使用組合索引，但是 優化器依然進行選擇
共勉，歡迎指導謝謝~
C. 資料庫基礎：講解MySQL索引的概念及資料庫索引的應用[1]
資料庫引入了索引
用戶對資料庫最頻繁的操作是進行數據查詢 一般情況下 資料庫在進行查詢操作時需要對整個表進行數據搜索 當表中的數據很多時 搜索數據就需要很長的時間 這就造成了伺服器的資源浪費 為了提高檢索數據的能力 資料庫引入了索引機制
有關 索引 的比喻
從某種程度上 可以把資料庫看作一本書 把索引看作書的目錄 通過目錄查找書中的信息 顯然較沒有目錄的書方便 快捷
資料庫索引實際是什麼告滲?(兩部分組成)
索引是一個單獨的 物理的資料庫結構 它是某個表中一列或若干列值的集合和相應的指向表中物理標識這些值的數據頁的邏輯指針清單
索引在表中的角色
一個表的存儲是由兩部分組成的 一部分用來存放表的數據頁面 另一部分存放索引頁面 索引就存放在索引頁面上
索引高效原理
通常 索引頁面相對於數據頁面來說小得多 當進行數據檢索時 系統先搜索索引頁面 從中找到所需數據的指針 再直接通過指針從數據頁面中讀取數據
索引的分類
在SQL Server 的資料庫中按存儲結構的不同將索引分為兩類 簇索引(Clustered Index)和非簇索引(Nonclustered Index)
( )簇索引對表的物理數據頁中的數據按列進行排序 然後再重新存儲到磁碟上 即簇索引與數據是混為一體 的它的葉節點中存儲的是實際的數據 由於簇索引對表中的數據一一進行了排序 因此用簇索引查找數據很快 但由於簇索引將表的所有數據完全重新排列了 它所需要的空間也就特別大 大概相當於表中數據所佔空間的 % 表的數據行只能以一種排序方式存儲在磁碟上 所以一個表只能有一個簇索引
( )非簇索引具有與表的數據完全分離的結構 使用非簇索引不用將物理數據頁中的數據按列襪友鍵排序 非簇索引的葉節點中存儲了組成非簇索引的關鍵字的值和行定位器 行定位器的結構和存儲內容取決於數據的存儲方式 如果數據是以簇索引方式存儲的 則行定位器中存儲的是簇索引的索引鍵;如果數據不是以簇索引方式存儲的 這種方式又稱為堆存儲方式(Heap Structure) 則行定位器存儲的是指向數據行的指針 非簇索引將行定位器按關鍵字的值用一定的方式排序 這個順序與表的行在數據頁中的排序是不匹配的 由於非簇索引使用索引頁存儲因此它比簇索引需要更多的存儲空間且檢索效率較低但一個表只能建一個簇索引 當用戶需要建立多個索引時就需要使用非簇索引了
小結 Clustered Index 是與物理數據混在一起並對物理數據進重排 就像使用拼音查字典;Unclustered Index 是與物理數據完全分離的 利用額外空間對關鍵字進行重排 就像使用部首查字典
資料庫索引應用
一 索引的概念
索引就是加快檢索表中數據的方法 資料庫的索引類似於書籍的索引 在書籍中 索引允許用戶不必翻閱完整個書就能迅速地找到所需要的信息 在資料庫中 索引也允許資料庫程序迅速地找到表中的數據 而不必掃描整個資料庫
二 索引的特點
索引可以加快資料庫的檢索速度
索引降低了資料庫插入 修改 刪除等維護任務的速度
索引創建在表上 不能創建在視圖上
索引既可以直接創建 也可以間接創建
可以在優化隱藏中 使用索引
使用查詢處理器執行SQL語句 在一個表上 一次只能使用一個索引
其他
三 索引的優點
創建唯一性索引 保證資料庫表中每一行數據的唯一性
大大加快數據的檢索速度 這也是創建索引的最主要的原因
加速表和表之間的連接 特別是在實現數據的參考完整性方面特別有意義
在使用分組和排序子句進行數據檢索時 同樣可以顯著減少查詢中分組和排序的時間
通過使用索引 可以在查詢告巧的過程中使用優化隱藏器 提高系統的性能
四 索引的缺點
創建索引和維護索引要耗費時間 這種時間隨著數據量的增加而增加
索引需要佔物理空間 除了數據表占數據空間之外 每一個索引還要佔一定的物理空間 如果要建立聚簇索引 那麼需要的空間就會更大
當對表中的數據進行增加 刪除和修改的時候 索引也要動態的維護 降低了數據的維護速度
lishixin/Article/program/MySQL/201311/29604
D. Mysql資料庫3種存儲引擎有什麼區別
Mysql資料庫3種存儲（MyISAM、MEMORY、InnoDB）引擎區別：
1、Myisam是Mysql的默認存儲引擎，當create創建新表時，未指定新表的存儲引擎時，默認使用Myisam。MEMORY、InnoDB不是默認存儲引擎。
2、InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比Myisam的存儲引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留數據和索引。
Mysql資料庫3種存儲（MyISAM、MEMORY、InnoDB）區別對比：
1、MyISAM
它不支持事務，也不支持外鍵，尤其是訪問速度快，對事務完整性沒有要求或者以SELECT、INSERT為主的應用基本都可以使用這個引擎來創建表。
數據文件和索引文件可以放置在不同的目錄，平均分配IO，獲取更快的速度。要指定數據文件和索引文件的路徑，需要在創建表的時候通過DATA DIRECTORY和INDEX DIRECTORY語句指定，文件路徑需要使用絕對路徑。
2、MEMORY
memory使用存在內存中的內容來創建表。每個MEMORY表實際對應一個磁碟文件，格式是.frm。MEMORY類型的表訪問非常快，因為它到數據是放在內存中的，並且默認使用HASH索引，但是一旦伺服器關閉，表中的數據就會丟失，但表還會繼續存在。
默認情況下，memory數據表使用散列索引，利用這種索引進行「相等比較」非常快，但是對「范圍比較」的速度就慢多了。因此，散列索引值適合使用在"="和"<=>"的操作符中，不適合使用在"<"或">"操作符中，也同樣不適合用在order by字句里。如果確實要使用"<"或">"或betwen操作符，可以使用btree索引來加快速度。
存儲在MEMORY數據表裡的數據行使用的是長度不變的格式，因此加快處理速度，這意味著不能使用BLOB和TEXT這樣的長度可變的數據類型。VARCHAR是一種長度可變的類型，但因為它在MySQL內部當作長度固定不變的CHAR類型，所以可以使用。
3、InnoDB
InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比MyISAM的存儲引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留數據和索引。
（1)自動增長列：
InnoDB表的自動增長列可以手工插入，但是插入的如果是空或0，則實際插入到則是自動增長後到值。可以通過"ALTER TABLE...AUTO_INCREMENT=n;"語句強制設置自動增長值的起始值，默認為1，但是該強制到默認值是保存在內存中，資料庫重啟後該值將會丟失。
可以使用LAST_INSERT_ID()查詢當前線程最後插入記錄使用的值。如果一次插入多條記錄，那麼返回的是第一條記錄使用的自動增長值。對於InnoDB表，自動增長列必須是索引。如果是組合索引，也必須是組合索引的第一列，但是對於MyISAM表，自動增長列可以是組合索引的其他列，這樣插入記錄後，自動增長列是按照組合索引到前面幾列排序後遞增的。
（2）外鍵約束：
MySQL支持外鍵的存儲引擎只有InnoDB，在創建外鍵的時候，父表必須有對應的索引，子表在創建外鍵的時候也會自動創建對應的索引。
E. mysql存儲引擎及索引類型有哪些
MyISAM、InnoDB、Heap(Memory)、NDB 貌似一般都是使用 InnoDB的，mysql的存儲引擎包括：MyISAM、InnoDB、BDB、MEMORY、MERGE、EXAMPLE、NDBCluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等，其中InnoDB和BDB提供事務安全表，其他存儲引擎都是非事務安全表。最常使用的2種存儲引擎:1.Myisam是Mysql的默認存儲引擎，當create創建新表時，未指定新表的存儲引擎時，默認使用Myisam。每個MyISAM在磁碟上存儲成三個文件。文件名都和表名相同，擴展名分別是.frm（存儲表定義）、.MYD(MYData，存儲數據)、.MYI(MYIndex，存儲索引)。數據文件和索引文件可以放置在不同的目錄，平均分布io，獲得更快的速度。2.InnoDB存儲引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是對比Myisam的存儲引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留數據和索引。不知道是不是對你有幫助
F. mysql資料庫，索引是怎麼使用的
MySQL支持很多數據類型，選擇合適的數據類型存儲數據對性能有很大的影響。通常來說，可以遵循以下一些指導原則：
(1)越小的數據類型通常更好：越小的數據類型通常在磁碟、內存和CPU緩存中都需要更少的空間，處理起來更快。
(2)簡單的數據類型更好：整型數據比起字元，處理開銷更小，因為字元串的比較更復雜。在MySQL中，應該用內置的日期和時間數據類型，而不是用字元串來存儲時間；以及用整型數據類型存儲IP地址。
(3)盡量避免NULL：應該指定列為NOT NULL，除非你想存儲NULL。在MySQL中，含有空值的列很難進行查詢優化，因為它們使得索引、索引的統計信息以及比較運算更加復雜。你應該用0、一個特殊的值或者一個空串代替空值。
G. 「Mysql索引原理（六）」聚簇索引
本節課主要關注InnoDB，但是這里討論的原理對於任何支持聚簇索引的存儲引擎都是適用的。
葉子節點包含了全部數據，其他節點只包含索引列。InnoDB將通過主鍵聚集數據，也就是說上圖中的「被索引的列」就是主鍵列。如果沒有定義主鍵，InnoDB會選擇一個唯一的非空索引代替。如果沒有這樣的索引InnoDB會隱式定義一個主鍵來作為聚簇索引。
如果主鍵比較大的話，那輔助索引將會變的更大，因為 輔助索引的葉子存儲的是主鍵值；過長的主鍵值，會導致非葉子節點佔用佔用更多的物理空間
所以建議使用int的auto_increment作為主鍵
主鍵的值是順序的，所以 InnoDB 把每一條記錄都存儲在上一條記錄的後面。當達到頁的最大值時，下一條記錄就會寫入新的頁中。一旦數據按照這種順序的方式載入，主鍵頁就會近似於被順序的記錄填滿。
聚簇索引的數據的物理存放順序與索引順序是一致的，即：只要索引是相鄰的，那麼對應的數據一定也是相鄰地存放在磁碟上的。如果主鍵不是自增id，那麼可以想 象，它會幹些什麼，不斷地調整數據的物理地址、分頁，當然也有其他一些措施來減少這些操作，但卻無法徹底避免。但，如果是自增的，那就簡單了，它只需要一 頁一頁地寫，索引結構相對緊湊，磁碟碎片少，效率也高。
因為MyISAM的主索引並非聚簇索引，那麼他的數據的物理地址必然是凌亂的，拿到這些物理地址，按照合適的演算法進行I/O讀取，於是開始不停的尋道不停的旋轉。聚簇索引則只需一次I/O。（強烈的對比）
不過，如果涉及到大數據量的排序、全表掃描、count之類的操作的話，還是MyISAM占優勢些，因為索引所佔空間小，這些操作是需要在內存中完成的。
MyISM使用的是非聚簇索引， 非聚簇索引的兩棵B+樹看上去沒什麼不同 ，節點的結構完全一致只是存儲的內容不同而已，主鍵索引B+樹的節點存儲了主鍵，輔助鍵索引B+樹存儲了輔助鍵。表數據存儲在獨立的地方，這兩顆B+樹的葉子節點都使用一個地址指向真正的表數據，對於表數據來說，這兩個鍵沒有任何差別。由於 索引樹是獨立的，通過輔助鍵檢索無需訪問主鍵的索引樹 。
所以說，聚簇索引性能最好而且具有唯一性，所以非常珍貴，必須慎重設置。 一般要根據這個表最常用的SQL查詢方式來進行選擇，某個欄位作為聚簇索引，或組合聚簇索引 ，這個要看實際情況。
聚簇索引和非聚簇索引的數據分布有區別，主鍵索引和二級索引的數據分布也有區別，通常會讓人感到困擾和以外，下面通過一個列子來講解InnoDB和MyISAM是如何存儲數據的：
該表的主鍵取值1~10000，按照隨機順序插入並使用optimize table命令做了優化。換句話說，數據在磁碟上的存儲方式已是最優，但行的順序是隨機的。列col2的值是從1~100之間隨機賦值，所以有很多重復的值。
MyISAM的數據分布很簡單，所以先介紹它。MyISAM按照數據插入的順序存儲在磁碟上，如下圖所示：
在行的旁邊顯示行號，從0開始遞增。因為行是定長的，所以MyISAM可以從表的開頭跳過所需的位元組找到需要的行。
col2上的索引
事實上，MyISAM中主鍵索引和其他索引在結構上沒有什麼不同。主鍵索引就是一個名為PRIMARY的唯一非空索引。
InnoDB支持聚簇索引，所以使用不同的方式存儲同樣的數據。
第一眼看上去，感覺和前面的沒什麼區別，但是該圖顯示了整個表，而不是只有索引。因為在InnoDB中，聚簇索引就是表，所以不像MyISAM那樣需要獨立的行存儲，這也是為什麼MyISAM索引和數據結構是分開的。
聚簇索引的每一個葉子節點都包含了主鍵值。事務ID、用於事務和MVCC的回滾指針以及所有的剩餘列。如果主鍵是一個列前綴索引，InnoDB也會包含完整的主鍵列和剩下的其他列。
還有一點和MyISAM不同的是，InnoDB的二級索引和聚簇索引很不相同。InnoDB的二級索引的葉子節點中存儲的不是「行指針」，而是主鍵值，並以此作為指向行的「指針」。這樣的策略減少了當出現行移動或者數據頁分裂時二級索引的維護工作。使用主鍵值當作指針會讓二級索引佔用更多的空間，換來的好處是，InnoDB在移動時無需更新二級索引中的這個「指針」。
我們在來看一下 col2索引 。
每一個葉子節點包含了索引列（這里是col2），緊接著是主鍵值（col1），上圖我們省略了非葉子節點這樣的細節。InnoDB非葉子節點包含了索引列和一個指向下一級節點的指針。
最後，以一張圖表示InnoDB和MyISAM保存數據和索引的區別。
前面講過，最好使用AUTO_INCREMENT自增列來聚集數據，避免隨機的、不連續的、值分布范圍大的列做聚簇索引，特別是對於I/O密集型的應用。例如，從性能角度考慮，使用UUID來作為聚簇索引則會很糟糕：他使得聚簇索引的插入變得完全隨機，這是最壞的情況，使得數據沒有任何聚集特性。
為了演示這一點，我們做兩個基準測試：
1、使用證書ID插入userinfo表，和uuid作為主鍵的userinfo_uuid表
userinfo_uuid表跟userinfo表除了主鍵給為UUID，其他欄位都一樣
測試這兩個表的設計，首先在一個有足夠內存容納索引的伺服器上向這兩個表各插入100萬條記錄。然後向兩個表繼續插入300萬數據，使索引的大小超過伺服器的內存容量。測試結果如下：
向UUID主鍵插入行不僅花費的時間更長，而且索引佔用的空間也更大。這一方面是由於主鍵欄位更長，另一方面毫無疑問是由於頁分裂和碎片導致的。
為了明白為什麼會這樣，來看看往第一個表中插入數據時，索引發生了什麼變化。
自整型主鍵插入
因為主鍵是順序的，所以InnoDB把每一條記錄都存在上一條記錄的後面。當達到頁的最大容量後，下一條記錄就會寫入到新的頁中。一旦數據按照這種順序的方式載入，主鍵頁就會近似於被順序的記錄填滿，這也正是所期望的結果。
UUID插入
因為新行的主鍵值不一定比之前插入的大，所以InnoDB無法簡單的總是把新行插入到索引的最後，而是需要為新的行尋找合適的位置，通常是已有數據的中間位置，並且分配空間。這會正價很多的額外工作，並導致數據分布不夠優化。
缺點：
把這些隨機值載入到聚簇索引後，也許需要做一次OPTIMIZE TABLE來重建表並優化頁的填充。
結論 ：使用InnoDB時應盡可能地按主鍵順序插入數據，並且盡可能地單調增加聚簇鍵的值來插入新行。