感覺好久沒有看MySQL相關的書了，最近邊複習，邊整理下感覺重要的知識點，一點點的由簡入繁，先從整體概念上理解下，擴充下整個知識圖譜。
一、MySQL 體系結構
基礎中有兩個重要概念，數據庫和數據庫實例。
數據庫：文件的集合，依照某種數據模型組織並存放於二級存儲器中的數據集合。
數據庫實例：是程序，位於用戶與操作系統之間的一層數據庫管理軟件，用戶對於數據庫的任何操作（DML，DDL）都是在數據庫實例下進行的，應用程序只有通過數據庫實例才能和數據庫打交道。
看了，最開始的架構圖，可以瞭解到MySQL 由以下組成
1、連接池組件
2、管理和工具組件
3、接口組件
4、解析器組件
5、優化器組件
6、緩存組件
7、插件式的存儲引擎
8、物理文件
注意：存儲引擎是基於表，而不是數據庫
二、存儲引擎
下面介紹幾個重要的存儲引擎的特點
1、InnoDB
特點：
-
支持事物，主要面向在線數據處理OLTP
-
支持行鎖設計
- 分爲共享鎖和排它鎖
- 行鎖有基本的三種算法
- record: 使用 ‘=’ 符號時，只查詢一行記錄的時候。
- Gap: 記錄不存在的時候退化爲這個，相同間隙鎖不衝突， 查詢id>20 其實也有可能鎖住11 ，因爲整個間隙都加鎖- Next key: Gap + record
-
支持外健.
-
使用next-key locking的策略來避免幻讀
-
通過多版本併發控制（MVCC）獲得高併發性，並實現了4種隔離級別，默認REPEATABLE.
-
插入緩衝（insert buffer）
- 插入緩衝,並不是緩存的一部分,而是物理頁,對於非聚集索引的插入或更新操作,不是每一次直接插入索引頁.而是先判斷插入的非聚集索引頁是否在緩衝池中.如果在,則直接插入,如果不再,則先放入一個插入緩衝區中.然後再以一定的頻率執行插入緩衝和非聚集索引頁子節點的合併操作
-
二次寫（double write）
- InnoDB 的Page Size一般是16KB，其數據校驗也是針對這16KB來計算的，將數據寫入到磁盤是以Page爲單位進行操作的。而計算機硬件和操作系統，在極端情況下（比如斷電）往往並不能保證這一操作的原子性，16K的數據，寫入4K 時，發生了系統斷電/os crash ，只有一部分寫是成功的，這種情況下就是 partial page write 問題.
- 所以簡單的說就是，在將數據寫盤的時候斷電了，一部分數據丟失後，根本不能從redo log來進行恢復了。其原理是在寫數據頁之前，先把這個數據頁寫到一塊獨立的物理文件位置（ibdata），然後再寫到數據頁。在宕機重啓後，先通過該副本還原數據頁，在使用redo log.
-
自適應哈希索引
- nnoDB採用自適用哈希索引技術，它會實時監控表上索引的使用情況，如果認爲建立哈希索引可以提高查詢效率，則自動在內存中的“自適應哈希索引緩衝區建立哈希索引
-
預讀
- 分爲線性預讀和隨機預讀
存儲其採用了聚集的方式，因此數據都是順序存儲，如沒有顯示的指定主鍵，會爲每一行數據生成一個6字節的ROWID作爲主鍵
2、MyISAM
不支持事物，表鎖設計，支持全文檢索，主要面向OLAP
緩衝池之緩存索引文件不緩衝數據
表由MYD 和MYI 組成，MYD存儲數據，MYI 存儲索引文件
3、NDB
集羣存儲引擎類似Oracle的RAC集羣
數據全部存放在內存中
（JOIN）連接操作是在mysql數據庫層完成的，而不是存儲引擎層完成。（複雜的連接操作需要巨大的網絡開銷，因此查詢巨慢）
4、Memory
表中數據存放在內存中，重啓數據消失
適用於臨時數據的臨時表，數據倉庫維度表。
默認是哈希索引，而不是B+樹索引
只支持表鎖，併發性能差，並不支持TEXT和BLOB類型。
存儲變長字段（varchart）時，是按照定長字段（char）方式進行，因此會浪費內存
如果MYSQL數據庫使用MEMORY存儲引擎作爲臨時表來存放查詢的中間結果集。如果結果集大於Memory存儲引擎設置的容量，又或者其中包含TEXT 和BLOB 數據類型字段，則MySQL數據庫會把其轉換到MYISAM存儲引擎表而存放到磁盤中。因M有ISAM不緩存數據文件，所以臨時表的查詢會損失性能。
先整體回顧了下大概的結構和知識點，下週主要針對InnoDB 做一個完整性的細節回顧
