普通索引index
唯一索引：主鍵索引primary key、唯一索引unique
聯合索引：聯合主鍵索引primary key(id, name)、聯合唯一索引unique(id, name)、聯合普通索引index(id, name)
通常使用b+樹來實現的索引，示例如下：
1）非葉子節點僅儲存索引，不儲存任何真實的資料值，所有的資料值，均儲存於葉子節點中，且每個葉子節點都有乙個指標指向下乙個葉子節點
2）圖中每乙個大方框代表乙個磁碟塊，每個磁碟塊中資料項的數量越多，一次檢索能夠縮小的範圍越多。而磁碟塊的大小一定，為此資料項的size越小，每個磁碟塊中儲存的資料量越多（這就是為何索引列欄位size應該盡量小）。
3）樹的高度越小，越快到達葉子節點，搜尋越快
2.2.1、復合索引
復合索引（name,id），以name建立b+樹，並將索引id存放於葉子節點中
基於b+樹實現，但是與myisam有所不同。示例如下：
1）innodb的主鍵索引的葉子節點中，儲存的是記錄的所有資料列，也就是說資料檔案本身就是索引檔案。myisam的葉子節點中儲存的是索引列，並且儲存記錄的位址，索引檔案和資料檔案是分開的。
2）innodb的普通索引（非主鍵索引）的葉子節點中，儲存的是索引列，以及對應的主鍵。使用普通索引時，先找到主鍵，再去主鍵索引中取資訊。
思考1：為何innodb的非主鍵索引中儲存的是主鍵索引，而不是和myisam一樣儲存記錄的位址？innodb的非主鍵索引為何要採用這種二次查詢的方式？
innodb在設計之初就考慮到資料的修改問題，每次修改，如果採用myisam的方式，就需要更新資料表中所有的索引中該記錄的位址資訊。而採用主鍵儲存記錄的方式，修改記錄只需要修改主鍵的相關葉子節點即可，不用再去維護普通索引的資訊。所以myisam適合查詢資訊，而innodb適合修改資訊。
為什麼使用like %a會導致索引失效？
如果使用%a這種前置模糊匹配的方式，每一條資料資訊，不管前面是什麼，後面都有很能和a字尾匹配，這個時候只能全表匹配，以防漏掉某條資料。
為何建立索引的資料列，其資料大小需要盡量小一些？
結合上面的索引示意圖，每乙個非葉子節點都是乙個磁碟塊，乙個磁碟塊中的索引節點越多：a、索引樹的高度會越小，搜尋也會越快到達葉子節點；b、每經過一次搜尋能夠鎖定的範圍也越小。而磁碟塊的大小是一定的，故當每個資料的大小越小，磁碟塊能夠儲存的索引節點越多。
如有不當之處，歡迎指正不勝感激
MySQL索引原理之索引原理
索引定義 是儲存引擎用於快速查詢記錄的一種資料結構。需要額外開闢空間和資料維護工作。索引是物理資料頁儲存，在資料檔案中 innodb，ibd檔案 利用資料頁 page 儲存。索引可以加快檢索速度，但是同時也會降低增刪改操作速度，索引維護需要代價。索引涉及的理論知識 二分查詢法 hash和b tree...
mysql索引 mysql索引實現原理
什麼是索引 索引是一種高效獲取資料的儲存結構，例 hash 二叉 紅黑。mysql為什麼不用上面三種資料結構而採用b tree 若僅僅是 select from table where id 45 上面三種演算法可以輕易實現，但若是select from table where id 6 就不好使了...
mysql 索引原理
b樹 b樹高度 資料庫為什麼使用這種結構？一般來說，索引本身也很大，不可能全部儲存在記憶體中，因此索引往往以索引檔案的形式儲存的磁碟上。這樣的話，索引查詢過程中就要產生磁碟i o消耗，相對於記憶體訪問，i o訪問的消耗要高幾個數量級，所以評價乙個資料結構作為索引的優劣最重要的指標就是在查詢過程中磁碟...