什麼是存儲引擎
存儲引擎位于檔案系統(各種資料，二進制形式)之上，各種管理工具(連接配接池、語義分析器、優化器、緩存區、SQL接口)之下。
存儲引擎功能設計
功能豐富性(或者SQL語義支援)：
事務(和檔案系統的最大差別)，鎖的粒度(行或者表)，全文索引，簇索引，外鍵(這是什麼)
事務：
事務的隔離性由鎖實作，其他ACD由redo log和undo logo實作。redo log保證事務原子性(怎麼了解？由于資料庫設計是先寫redo，再執行真正修改資料頁。是以redo一定是個完整的事務，才會修改資料頁)和持久性(怎麼了解?持久化到硬碟)。undo log保證事務一緻性(資料沖突時的恢複)。
redo 寫法是資料庫一直順序寫，無需讀。由于沒有使用O_DIRECT裸寫盤，是以每次寫redo 必須fsync到硬碟。
另外這裡還有提到的是binlog，區分的是binlog是資料庫容災的範籌(記錄的是sql語句，在事務送出的時候才會寫)。而redo是innodb産生的(修改頁的實體二進制日志，随事務進行而并發寫)。而且在寫redo是以日志塊大小和磁盤扇區一樣。都是512位元組。是以重寫日志寫入具有原子性。redo的實體二進制日志，以不記錄sql語句執行過程，而記錄sql執行後的頁結果。由此具有幂等性(執行多次等同于執行一次，分布式網絡的不可靠 由于多次重新調用接口，必須保證幂等性)。
一個問題是，基于硬碟的資料庫會把資料寫在記憶體中，同時對資料庫的修改最初也是改在記憶體上，怎麼落地呢(checkpoint檢查點機制)。事務資料庫為了保證ACID的D一般會使用先寫redo log，在修改頁。
undo幫助事務復原和MVCC功能。
表鎖、行鎖：
鎖機制分為latch(輕量級的鎖，分為mutex和rwlock。這個是内部鎖機制，保證并發線程操作臨界資源的正确性，通常沒有死鎖檢測機制, 比如檢視mutex的方法是show engine innodb mutex;)和lock(粒度為事務，可以是表、頁、行，有死鎖檢測機制)。
死鎖檢測機制有：順序擷取多個鎖(latch隻有這個機制)，waits-for graph(圖死鎖檢測)，過期機制。
MVCC機制(解決鎖帶來争用的分布式并發通路問題)
自增長鎖：給每個插入賦予一個唯一增加的id，每個插入擷取到這個id，就可以釋放表鎖。通過減少鎖的持有時間，提高并發插入效率。
檢視目前事務隔離級别：
mysql> SELECT @@tx_isolationG;*************************** 1. row ***************************@@tx_isolation: REPEATABLE-READ
幻讀和髒讀：髒讀都不好嗎？在slave節點可以修改innodb的預設事務隔離級别REPEATEDLY READ為READ UNCONMITTED，允許讀到不那麼準确的資料。
不可重複讀：一般不可重複讀是可以接受的，因為他讀到的是送出的資料，而髒讀是讀到未送出的資料。如Oracle和SQL Server設定的事務隔離級别是READ CONMIITTED，則會出現不可重複讀現象。
丢失更新：一個事務更新會被另一個事務更新所覆寫，進而産生資料不一緻。基本資料庫任何隔離級别，不會産生。
資料存儲設計：
支援B樹索引，支援hash索引，資料壓縮存儲，資料表緩存(或者隻索引緩存)，資料檔案加密，存儲效率，記憶體消耗，硬碟消耗，塊插入速度，查詢緩存，MVCC(解決并發資料一緻性問題)。
B+樹索引／自适應hash索引：
B樹(Blance樹或者平衡樹)：關系型資料庫最常用拿來做索引的。從AVL(平衡二叉樹演化而來)。
B+樹=B樹+索引順序通路。包含樹枝節點和葉子節點。所有的資料放在葉子節點。每一個葉子節點互相有序順序連接配接。樹根節點指引着查找到葉子節點的路徑。由于不斷的插入和删除，同時B+樹會通過旋轉保持平衡。
B+索引本身并不是找到具體的一條記錄，而是找到該記錄所在的頁。資料頁把載入到内中，然後通過頁目錄在進行二叉查找。因為在記憶體查找很快。
聚集索引：按照表的主鍵建構的B+樹。
輔助縮影：葉子節點存放的不是資料，而是捷徑，指引到找到所有資料的地方。
資料的區分度：Cardinality
自适應哈希索引：innodb根據查找頻度，建立hash索引。将o(logn)的查找複雜度提高最快o(0)(最慢o(n))的速度。哈希索引不對範圍查找有效。
壓縮空間和加密安全：
記錄在檔案可以是普通模式或者reduction模式。
容災機制：
備份機制，備份恢複(備份快照點記錄)。熱備，冷備，溫備。
新上一台備機的備份順序是記住目前主資料庫的LSN(log squence number)，導出主資料庫的目前資料庫并在備機導入。設定LSN同步點。
innodb特性
特性：
- innodb架構：多線程模型(Master，IO，Purge，Page Cleaner)，資料重新整理到硬碟才是sql(事務)執行完的标志嗎。purge是完成事務送出後情況undo log。
- 記憶體的消耗大(大在哪裡？)。記憶體消耗在具體在緩沖區。緩沖區除了保護有資料頁，索引頁，還有undo頁，插入緩沖。自适應hash索引、鎖資訊、字典資訊。為什麼innodb的記憶體會比其他的存儲引擎大呢？
- 什麼是資料庫執行個體(類似于伺服器的程序，資料庫是資料檔案)
- 緩沖區的基本管理思路是LRU。37為距離LRU追加尾部的37%位置，并且隻有在mid位置當超過block_times的時候才要可以會被移到mid的熱點。當然使用者預估自己的熱點資料，适當得增加mid之前的熱點區域。其中page made young和page not made young就表示了頁從old移到new或者由于block_time的限制，old沒能移到new。從information_schema資料庫的select * from innodb_buffer_pool_statsG;可以擷取到。可以看到這裡還是很多old往new的遷移過程當中被block住。(我覺得這裡made yong的過程中，是不是有很多熱點資料，有沒有必要把mid位置調長些)。第一個執行個體：緩沖區空間size：8192*16K=128M。LRU表項用DATABASE_PAGES表示。FREE_BUFFERS是可利用的頁。
- 主線程：每秒鐘循環和每10秒鐘循環
- 重做日志的LSN(Log Sequeence Number)标記版本。
- Sharp Checkpoint和Fuzzy Checkpoint(主線程定時的重新整理，LRU頁不夠必須删除尾巴頁，重做日志不可用，髒頁太多)
- 資料庫的容災：重做日志+LRU。LRU溢出需要寫磁盤。重做日志由于磁盤空間必須部分删除需要寫磁盤
innodb關鍵特性：
- 插入緩沖：針對非聚集索引的插入或者更新。針對非唯一輔助索引。
- 兩次寫：寫的壓力大不大，總共寫記憶體多少Innodb_dblwr_pages_written(真實反映資料庫的)，硬碟持久化多少次Innodb_dblwr_writes
- 自适應hash索引：要求通路模式比較單一
- AIO：AIO的好處和壞處。：| innodb_flush_neighbors | 1 |
- 重新整理鄰接頁(預讀)。但是如果是本來 就是iops比較高的儲存設備還需要這個嗎，因為這個是對機械硬碟相鄰資料寫入做優化，或者有沒有可能領接頁寫入重新整理了 又很快變為髒頁。
檢視目前資料庫運作性能
show global status like 'com_select';列出 自資料庫啟動以來的所有連接配接
檢視資料庫的線程資料來窺探性能
檢視緩存區狀态
LRU檢視
mysql> show variables like '%old_block%';+------------------------+-------+| Variable_name | Value |+------------------------+-------+| innodb_old_blocks_pct | 37 || innodb_old_blocks_time | 1000 |+------------------------+-------+
檢視目前資料庫的運作狀态還有
show engine innodb status。show variables;show status;
備份相關
show binlog events in 'bin-log.000004'Gshow master statusshow slave statusshow binary logs;檢視所有的二進制日志show variables like '%sync_binlog%'binlog檔案轉換每次伺服器啟動都開啟一個新的二進制日志。檔案大小超過限制将會建立一個新的檔案。