感覺好久沒有看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 做一個完整性的細節回顧