順序io（不需要每次都磁盤尋址，效率高），隨機io（需要每次都磁盤尋址，效率低）

如何正確的創建合適的索引？

索引是一種分散存儲的數據結構

磁盤io特性：每次交互是以頁為單位，每頁4K數據。innoDB每次和磁盤交互是四頁16k數據（InnoDB葉節點data域保存了完整的數據記錄相比較MYISAM(因為只存儲了葉子節點的指針，所占空間1kb都不到)更能充分利用每次磁盤io）

InnoDB 主鍵索引存儲了完整的數據庫記錄行，輔助索引僅存儲了索引和主鍵值（這里提供了一種解決海量數據分頁問題的思路，例如要取一張千萬級別數據的表中5百萬到5百萬零五十行的記錄，如何快速獲取，可以先使用輔助索引查詢找主鍵，再通過主鍵走主鍵索引獲取數據庫記錄。）

mysql索引底層使用的是B+樹，索引所有元素都位于樹的葉子節點,相鄰葉子節點間有雙向指針查找索引時先將根節點load到磁盤中（這是一個磁盤IO過程，比較耗時，）在節點中定位指向下一級節點的指針，三層B+樹飽和狀態能存儲大概2000萬個索引

什么叫做聚集索引（聚簇索引）？

就是索引鍵值的邏輯順序跟表數據行的物理存儲順序是一致的。（比如字典的目錄是按拼音排序的，內容也是按拼音排序的，按拼音排序的這種目錄就叫聚集索引）。

MYISAM引擎主鍵是非聚族索引，索引和數據分開存儲的，? 不支持事務

InnoDB是主鍵索引是聚族索引，查詢的時候不用回表，少一次磁盤IO；? 支持事務

聚族索引，B+樹葉子節點不僅包含指針還包含數據

雖然InnoDB也使用B+Tree作為索引結構，但具體實現方式卻與MyISAM截然不同。

第一個重大區別是InnoDB的數據文件本身就是索引文件。MyISAM索引文件和數據文件是分離的，索引文件僅保存數據記錄的地址。而在InnoDB中，表數據文件本身就是按B+Tree組織的一個索引結構，這棵樹的葉節點data域保存了完整的數據記錄。這個索引的key是數據表的主鍵，因此InnoDB表數據文件本身就是主索引。

無用的索引會拖垮數據庫操作的性能（更新刪除新增樹的結構要變化，節點內關鍵字會重排）

myisam引擎中B+樹數據庫記錄行的指針（5.5版本之前的默認引擎）

innodb引擎主鍵索引葉子節點存儲了索引和數據記錄（5.5版本之后的默認引擎）

列的離散性越高，選擇性就越好（離散型太低還不如全表掃描，不適合建立索引）

離散性太差，mysql可能自動不選擇索引（由mysql的查詢優化器實現）

前綴索引：當需要給長度很長的字符串字段加索引時，可以使用前綴索引，給字符串的前幾個字符位加索引，需要先判斷一下前幾位字符的離散度也就是重復率。

聯合索引：選擇原則：

1、經常用的列優先（最左匹配原則）

2、選擇性（離散度）高的列優先（離散型高原則）

3、寬度小的列優先（最少空間原則）

覆蓋索引：

1、如果查詢里可通過索引節點中的關鍵字直接返回，則稱為覆蓋索引

例 user表中 聯合索引為name+age? 查詢語句為select name, age from user where name=?

則為覆蓋索引，直接返回葉子節點位置的數據，不用再回表，大大減少磁盤io，提高性能（這就是為什么公司不讓使用select * ，有可能命中覆蓋索引，只返回必要的數據，減少數據包的大小，降低數據傳輸的開銷）

索引失效的情況

1.where條件中not in、or和<>操作無法使用索引（離散型太差）;

2.復合索引未用左列字段;

3.like以%開頭;

4.需要類型轉換;

5.where中索引列有運算;

6.where中索引列使用了函數;

7.如果mysql覺得全表掃描更快時（數據少，離散型差等情況）;

插拔式存儲引擎

CSV存儲引擎：

(數據存儲以CSV文件格式）

特點：不能定義沒有索引、列定義必須為not null 、不能設置自增列

-->不適用大表或者數據的在線處理

CSV數據的存儲用逗號隔開，可直接編輯CSV文件進行數據的編排

-->數據安全性低

應用場景：數據的快速導入導出，表格直接裝換成CSV

Archive存儲引擎：

壓縮協議進行數據的存儲（ARZ文件格式）

特點：只支持insert和select兩種操作，只允許自增id建立索引，行級鎖，不支持事務，數據占用磁盤少

應用場景：日志系統，大量的設備數據采集

Memory存儲引擎（heap存儲引擎）

Myisam存儲引擎

特點：select count(*) from table無需進行數據的掃描

? ? ? ? 數據（MYD）和索引（MYI）分開存儲

? ? ? 表級鎖

? ? ? 不支持事務

Innodb（5.5版本后的默認存儲引擎）

? ? ? ? ? ? 支持事務、 行級鎖、聚集索引，支持外鍵