b+樹索引的使用
我們日常使用中，索引可以引用了很多列，而不是單一列的索引。
1、如果不是按照索引的最左列開始查詢，則無法使用索引。
2、不能跳過索引中的列，否則生效的只能是索引左側沒跳過的列。
3、如果查詢中有某個列是範圍查詢，則其右邊的列都無法使用索引優化查詢。
上面三條意味著，索引中列的順序，至關重要。
聚簇索引、非聚簇索引
我還以為聚簇索引會是什麼新的資料結構，不是的，它指的是實現b+樹的內容構成的不同。聚簇索引就是乙個b+樹的索引（innodb）。
在innodb，聚簇索引是根據主鍵值自動生成的，也叫主鍵索引，葉子節點存的就是每一行的值。懂了吧，innodb的每張表的儲存形式，本身就是乙個b+樹。
其他我們自己加的自定義索引，都叫做輔助索引，也叫做非聚簇索引，也叫二級索引，也叫非主鍵索引。。。。
明明就這麼簡單的東西，非得搞上這麼多術語，顯得很高大上的樣子。個人覺得這種簡單的概念表就不用加上這種術語索引了，而且重複構造了索引，服了。
如果沒有唯一主鍵，或者沒有唯一標識的資料列，innodb會自動新增乙個6位元組（差不多281萬億條長度）的自增主鍵。
輔助索引的葉子節點的值，是主鍵。
所以我們通過輔助索引查詢的話，會先去找輔助索引的b+樹，得到主鍵值，然後再去聚簇索引找到那一行的值。
這也是為什麼innodb不喜歡主鍵值太長，也不喜歡主鍵值雜亂無意義的原因了。
主鍵值太長，所有的輔助索引就會很大。主鍵雜亂無意義，那麼不好構建聚簇索引。
我們以後設計主鍵，盡量使用自增整數吧。
雜湊索引
只有memory引擎顯式支援雜湊索引（ndb集群所有也支援）。
innodb引擎有個特殊的功能，叫做自適應雜湊索引（adaptive hash index），當innodb注意到某些索引值被使用的非常頻繁的時候，會在記憶體中，基於b-tree的索引上，自行建立乙個雜湊索引，這個行為不受使用者控制，但是可以被手動關閉。
雜湊索引，就是為索引內的所有列計算乙個雜湊碼。
只有精準匹配所有所有列的查詢才有效。如果不同行的資料的雜湊碼的值 相同，則鍊錶形式存放。
跟hash表沒啥不同。
雜湊索引的缺陷：這裡的實現無法sorted（按照索引排序），也不支援部分匹配。
自行建立雜湊索引
我們也可以自行建立自適應雜湊索引，手動為每一行計算雜湊值。比如使用crc32()函式。
為啥不用sha1()或者md5()呢？因為這兩個函式計算出來的雜湊值是非常長的。。。
還可以使用fnv64()函式，速度快，衝突比crc()少很多。
空間資料索引（r-tree）
這個空間索引，不得不讓人想起redis的geo資料型別。也是經典存經緯度。
什麼是r-tree
什麼是r樹
r-tree不僅使用平面經緯度，也適合高緯度搜尋。
mysql需要使用mbrcountains()來維護地理資料。但支援並不完善，多數人不會使用它。
全文索引
頁碼299
這種型別的索引，在搜尋引擎比較常見。
我們可以試想使用場景，乙個搜尋框。
如果這些相關資料都超級無敵長，難道我們要乙個乙個比較過去嗎？想想也不現實吧。
所以，這不是一種精確查詢，而是一種相似度查詢。
在mysql中要良好使用的話，最好搞個外掛程式擴充套件下全文索引的功能。意思就是mysql寫的**還有大的進展空間唄。
整個索引**現次數最小的詞語，那麼這個詞語的相關度就很高，如果索引裡這個詞出現次數很多，那麼這個詞甚至都不會被搜尋。界限大概是1半。
select film_id,title,right(desciption,25),match(title,description) against('factory casualties') as relevance from ***x where match(title,description) against('factory casualties');只有查詢的列，完全等於全文索引的列，才會使用全文索引。
全文索引的內容還挺多的，可能只會會再增加一章專門講這個。
分形樹索引
算是對b+樹的增強吧。
覆蓋索引
這貨也不是什麼新的資料結構，也是b族的樹。
重點指的是，如何設定索引包含的列，要查詢的值跟篩選的條件，在同乙個索引裡面。因為這樣，查詢的值，會存在輔助索引檔案處。就不用再去找一遍聚簇索引。相當於用空間換時間了。
參考：覆蓋索引
索引的用處，何時使用索引
綜上，我們可以很明顯的感覺出，索引是在資料的基礎上，構建了不同的資料結構，能夠快速的定位到需要查詢的資料。
我們需要均衡構建索引的成本以及使用索引帶來的增益。
如果表的量很小，那麼就不需要使用索引。
如果表的數量特別多，那麼單單使用索引可能不夠，還可以使用分表、分割槽一起使用。
mysql高效能索引 mysql高效能索引（ ）
在開發中，我們知道大多數應用的瓶頸在於sql語句的執行時耗，在這裡並不討論sql語句的安全，僅僅討論高效能sql語句，而與高效能sql語句緊密相連的就是傳說中的 索引。索引 一種工作在儲存引擎端的用於快速找到記錄的一種資料結構。mysql使用索引的方式是 先找到索引的值，再根據索引的值找到資料行。索...
高效能mysql（一） 建立高效能索引
單列索引和多列索引 單列索引 多個單列索引的選擇問題 多個or條件 多個單列的效能往往效能很低，盡量建立高效的多列索引。多列索引 選擇合適的索引順序 避免範圍條件 在where子句中，in是有效的，範圍條件會導致後面的索引無效！在order by中，範圍條件和in都會導致無法按照索引排序！按照索引順...
MySQL資料高效能索引
索引 類似資料的目錄，mysql儲存引擎使用類似方式進行查詢，先去索引找到對應的值，然後根據匹配的索引找到對應的資料行 索引對效能的影響 大大減少伺服器需要掃瞄的資料量。比如我們資料表1000條資料。我們只需要根據條件查詢其中的一條，我們針對這一列建立乙個索引，我們只需要掃瞄著一條就可以了。如果不建...