磁盤基本概念
磁盤由大小相同且同軸的圓形盤片組成，磁盤的一側有磁頭支架，磁頭支架固定了一組磁頭，每個磁頭負責存取一個磁盤的內容。磁盤塊/簇（虛擬出來的）。 塊是操作系統中最小的邏輯存儲單位。操作系統與磁盤打交道的最小單位是磁盤塊。
通俗的來講，在Windows下如NTFS等文件系統中叫做簇；在Linux下如Ext4等文件系統中叫做塊（block）。每個簇或者塊可以包括2、4、8、16、32、64…2的n次方個扇區。
爲什麼存在磁盤塊？
讀取方便：由於扇區的數量比較小，數目衆多在尋址時比較困難，所以操作系統就將相鄰的扇區組合在一起，形成一個塊，再對塊進行整體的操作。
分離對底層的依賴：操作系統忽略對底層物理存儲結構的設計。通過虛擬出來磁盤塊的概念，在系統中認爲塊是最小的單位。
由於存儲介質的特性，磁盤本身存取就比主存慢很多，再加上機械運動耗費，磁盤的存取速度往往是主存的幾百分分之一，
所以每次都會預讀，即使只需要一個字節，磁盤也會從這個位置開始，順序向後讀取一定長度的數據放入內存，
預讀的長度一般爲頁（page）的整倍數。頁是計算機管理存儲器的邏輯塊，硬件及操作系統往往將主存和磁盤存儲區分割爲連續的大小相等的塊，每個存儲塊稱爲一頁（在許多操作系統中，頁得大小通常爲4KB，InnoDB存儲引擎中頁的大小爲16KB），主存和磁盤以頁爲單位交換數據。
扇區、塊/簇、page的關係
- 扇區： 硬盤的最小讀寫單元
- 塊/簇： 是操作系統針對硬盤讀寫的最小單元
- page： 是內存與操作系統之間操作的最小單元。
扇區 <= 塊/簇 <= page
B-/+Tree索引的性能分析
數據庫系統的設計者巧妙利用了磁盤預讀原理，將一個節點的大小設爲等於一個頁，這樣每個節點只需要一次I/O就可以完全載入。
複雜度爲O(h)=O(logdN)，h表示樹的高度，d表示頁的寬度
B-Tree
B+Tree
爲什麼使用B-Tree（B+Tree）
紅黑樹等數據結構也可以用來實現索引，但是文件系統及數據庫系統普遍採用B-/+Tree作爲索引結構，評價一個數據結構作爲索引的優劣最重要的指標就是在查找過程中磁盤I/O操作次數的漸進複雜度，而紅黑樹這種結構h（高度）明顯要深的多，所以紅黑樹的I/O漸進複雜度也爲O(h)，效率明顯比B-Tree差很多。由於B+Tree內節點去掉了data域，因此可以擁有更大的出度，擁有更好的性能。
MyISAM索引實現
MyISAM引擎使用B+Tree作爲索引結構（非聚集），葉節點的data域存放的是數據記錄的地址。主索引和輔助索引（Secondary key）在結構上沒有任何區別，只是主索引要求key是唯一的，而輔助索引的key可以重複。
InnoDB索引實現
InnoDB引擎使用B+Tree作爲索引結構（聚集索引）的數據文件本身要按主鍵聚集，所以InnoDB要求表必須有主鍵（MyISAM可以沒有），如果沒有顯式指定，則MySQL系統會自動選擇一個可以唯一標識數據記錄的列作爲主鍵，如果不存在這種列，則MySQL自動爲InnoDB表生成一個隱含字段作爲主鍵，這個字段長度爲6個字節，類型爲長整形。葉子節點往上部分只起到索引效果，數據都是存放在葉子節點當中的。查數據都要走到葉子節點，所以說穩定性很高。輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄。不建議使用過長的字段作爲主鍵，因爲所有輔助索引都引用主索引，過長的主索引會令輔助索引變得過大。
InnoDB的主鍵選擇
插入數據時候，如果InnoDB頁大小達到裝載因子（InnoDB默認爲15/16），則開闢一個新的頁（節點）。
如果表使用自增主鍵，那麼每次插入新的記錄，記錄就會順序添加到當前索引節點的後續位置，當一頁寫滿，就會自動開闢一個新的頁。這種自增主鍵會形成連續的填充，避免頁的碎片化。
索引優劣
優勢：
- 提高數據的檢索效率，降低數據庫的IO成本。
- 降低CPU的消耗，節能hh。
劣勢：
- 實際上索引也是一張表，表中保存了主鍵和索引字段，並指向實體類的記錄，所以索引列也是要佔用空間的。
- 會降低表更新的速率。每一次表中的insert，update，delete都會使索引維護。
索引分類
單值索引
這也是最常見到的
就是對單個字段（列）建一個索引
每個索引只負責它接管的列數據
一個表中可以包含多個單值索引
唯一索引
前提就是單個字段（列）的值是唯一的，可以包含空值
複合索引
一個索引當中包含了多個字段（列）
對應sql查詢，相當於根據XX查找XX。
主鍵索引
mysql默認創建的
爲什麼一定要用InnODB?
一、關於count(*)
知識點：MyISAM會直接存儲總行數，InnoDB則不會，需要按行掃描。
潛臺詞是，對於select count(*) from t; 如果數據量大，MyISAM會瞬間返回，而InnoDB則會一行行掃描。
實踐：數據量大的表，InnoDB不要輕易select count(*)，性能消耗極大。
常見坑：只有查詢全表的總行數，MyISAM纔會直接返回結果，當加了where條件後，兩種存儲引擎的處理方式類似。
例如：
t_user(uid, uname, age, sex);
-
uid PK
-
age index
select count(*) where age<18 and sex='F';
查詢未成年少女個數，兩種存儲引擎的處理方式類似，都需要進行索引掃描。
啓示：不管哪種存儲引擎，都要建立好索引。
二、關於全文索引
知識點：MyISAM支持全文索引，InnoDB5.6之前不支持全文索引。
實踐：不管哪種存儲引擎，在數據量大併發量大的情況下，都不應該使用數據庫自帶的全文索引，會導致小量請求佔用大量數據庫資源，而要使用《索引外置》的架構設計方法。
啓示：大數據量+高併發量的業務場景，全文索引，MyISAM也不是最優之選。
三、關於事務
知識點：MyISAM不支持事務，InnoDB支持事務。
實踐：事務是選擇InnoDB非常誘人的原因之一，它提供了commit，rollback，崩潰修復等能力。在系統異常崩潰時，MyISAM有一定機率造成文件損壞，這是非常煩的。但是，事務也非常耗性能，會影響吞吐量，建議只對一致性要求較高的業務使用複雜事務。
畫外音：Can't open file 'XXX.MYI'. 碰到過麼？
小技巧：MyISAM可以通過lock table表鎖，來實現類似於事務的東西，但對數據庫性能影響較大，強烈不推薦使用。
四、關於外鍵
知識點：MyISAM不支持外鍵，InnoDB支持外鍵。
實踐：不管哪種存儲引擎，在數據量大併發量大的情況下，都不應該使用外鍵，而建議由應用程序保證完整性。
五、關於行鎖與表鎖
知識點：MyISAM只支持表鎖，InnoDB可以支持行鎖。
分析：
MyISAM：執行讀寫SQL語句時，會對錶加鎖，所以數據量大，併發量高時，性能會急劇下降。
InnoDB：細粒度行鎖，在數據量大，併發量高時，性能比較優異。
實踐：網上常常說，select+insert的業務用MyISAM，因爲MyISAM在文件尾部順序增加記錄速度極快。樓主的建議是，絕大部分業務是混合讀寫，只要數據量和併發量較大，一律使用InnoDB。
常見坑：
InnoDB的行鎖是實現在索引上的，而不是鎖在物理行記錄上。潛臺詞是，如果訪問沒有命中索引，也無法使用行鎖，將要退化爲表鎖。
畫外音：Oracle的行鎖實現機制不同。
啓示：InnoDB務必建好索引，否則鎖粒度較大，會影響併發。
總結
在大數據量，高併發量的互聯網業務場景下，對於MyISAM和InnoDB
-
有where條件，count(*)兩個存儲引擎性能差不多
-
不要使用全文索引，應當使用《索引外置》的設計方案
-
事務影響性能，強一致性要求才使用事務
-
不用外鍵，由應用程序來保證完整性
-
不命中索引，InnoDB也不能用行鎖
結論
在大數據量，高併發量的互聯網業務場景下，請使用InnoDB:
-
行鎖，對提高併發幫助很大
-
事務，對數據一致性幫助很大
這兩個點，是InnoDB最吸引人的地方。
參考：
https://www.cnblogs.com/jinyuanya/p/optimize.html
http://blog.codinglabs.org/articles/theory-of-mysql-index.html
http://www.csyt.cc/news/info/520.html
https://www.cnblogs.com/rouqinglangzi/p/11144960.html
https://blog.csdn.net/qq_17033579/article/details/82950096
https://www.cnblogs.com/roadlandscape/p/12753790.html
btree索引和hash索引的區別