後台線程
•Master Thread
核心後台線程，主要負責將緩沖池的數據異步刷新到磁盤。例如髒頁的刷新，插入緩沖的合並，undo 頁的回收等。
每秒一次的操作：
1.日志緩沖刷新到磁盤，即使該事務還沒有提交。該操作總是會發生，這個就是為了再大的事務，提交時間都很短。
2.當IO壓力很小時（1s內發生的IO次數小於5% innodb_io_capacity）合並5% innodb_io_capacity 的插入緩沖。
3.當髒頁比例大於 innodb_max_dirty_pages_cnt, 刷新 innodb_io_capacity 個緩沖池中的髒頁到磁盤。否則如果 innodb_adaptive_flush 開啟，則根據buf_flush_get_desired_flush_rate 來選擇合適刷新髒頁數量進行刷新。
每10秒一次的操作：
1.如果過去10S 內IO操作小於 innodb_io_capacity， 刷新 innodb_io_capacity 個緩沖池中的髒頁到磁盤。
2.合並5% innodb_io_capacity 個插入緩沖。
3.將日志緩沖刷新到磁盤。
4.刪除無用的undo頁。
5.如果緩沖池中髒頁比例超過70%，再次刷新 innodb_io_capacity 個髒頁到磁盤。否則刷新10% innodb_io_capacity 個髒頁。
background loop(數據庫空閒或者數據庫關閉時):
1.刪除無用的undo頁。
2.合並 innodb_io_capacity 個插入緩沖。
flush loop(數據庫空閒）：
1.刷新 innodb_io_capacity 個髒頁
•IO Thread
Innodb存儲引擎大量使用了AIO， IO Thread主要負責IO請求的回調。 可使用innodb_read_io_threads和innodb_write_io_threads參數列表調整。
•Purge Thread
事務提交後。該事務相關的undolog可能不再需要。Purge Thread就是用來回收不需要的undo頁的。
•PageCleaner Thread
負責髒頁的刷新操作。減輕master thread的工作以及對於用戶查詢線程的阻塞。
內存緩沖池
對於數據庫中頁的修改操作，首先修改在緩沖池中的頁，然後再以一定的頻率刷新到磁盤上。這就意味著不是每次緩沖池中的頁修改時觸發刷新回磁盤，而是通過checkpoint技術刷新回磁盤。緩沖池的大小配置可通過 innodb_buffer_pool_size來設置。
緩沖池的數據頁類型有：數據頁，索引頁，undo頁，插入緩沖，自適應哈希索引，innodb存儲的鎖信息，字典信息。
現在innodb存儲引擎允許多個緩沖池實例。這樣通過hash到不同緩沖池實例來減少鎖的競爭。該參數可以通過innodb_buffer_pool_instance.
緩沖池是一個很大的內存區域，數據庫通過LRU算法來進行管理。但是因為考慮到全表掃描的操作。因此沒有采用樸素的LRU算法。LRU列表中加入的midpoint位置。新讀取到的頁，並不是直接放到lru列表的首部，而是midpoint位置。默認情況下，在lru列表長度的5/8處。由參數innodb_old_blocks_pct控制。
插入緩沖
對於非聚集索引的插入和更新操作，Innodb存儲引擎並不是直接插入到索引頁中，而是的Insert Buffer。然後再以一定的頻率進行insertbuffer和輔助索引葉子節點的merge。著通常將多個隨機插入合並到一個操作中。大大提高了非聚集索引插入的性能。
Innodb使用 insertbuffer 條件：
•索引是非聚集索引
•索引不是unique的(如果是unique, 則又需查找索引來保證unique)
Insert Buffer 內部實現
Insert Buffer 的數據結構是一棵B+樹。 Mysql 4.1後，全局只有一棵B+樹，負責對所有表的輔助索引進行insert Buffer. 並且，這棵樹存放在共享表空間裡，默認情況下即ibdata1。因此，如果僅通過獨立表空間ibd文件恢復表中數據時，可能會導致失敗。還需要通過insert buffer數據恢復表上的輔助索引。
Insert Buffer 的非葉節點存放的是查詢key, 構造如 space(4字節） + marker（1字節） + offset（4字節）。space表示記錄所在表的表空間ID，offset表示頁的偏移量。marker用來兼容老版本。
Insert Buffer 葉子幾點構造如 space + marker + offset + metadata + records。 space, marker, offset和前述意義相同。 metadata裡的 IBUF_REC_OFFSET_COUNT保存了兩個字節的整數，用來排序記錄進入 Insert Buffer 的順序。通過這個順序回訪呢個得到記錄的正確值。從Insert Buffer 葉子節點的第5列開始，才是實際插入的各個記錄。
啟用 Insert Buffer索引後，輔助索引頁的記錄可能被插入到 Insert Buffer B+樹中。為了保證每次合並插入緩沖區成功， 必須要有一塊地方能標記每個輔助索引頁的可用空間。 Insert Buffer采用一個特殊的頁來標記，該頁的類型為 Insert Buffer Bitmap。每個 Insert Buffer Bitmap頁用來追蹤16384個頁，也就是256個區。每個Insert Buffer Bitmap 頁都在16384個頁的第二個頁。每個輔助索引頁在Bit map中占用4個字節，這裡面主要用於表示輔助索引頁的可用數量。
合並插入緩沖
Insert Buffer中的記錄在以下情況下合並到真正的輔助索引中：
• 輔助索引頁被讀到緩沖池中；
• Insert Buffer Bitmap 頁追蹤到該輔助索引頁已無可用空間時；
• Master Thread調度時；
這樣子，對輔助索引頁的多次記錄操作通過一次操作合並到了原有的輔助索引頁中，從而提高性能。
兩次寫（Double Write)
InsertBuffer 給 Innodb 存儲引擎帶來了性能的提升，而兩次寫帶給 Innodb 存儲引擎的是數據頁的可靠性。
可能會有疑問，如果發生寫失敗，那麼不是可以通過重做日志進行恢復的嗎？這的確是一個辦法，但是必須知道，重做日志記錄的是頁的物理操作，如偏移量800， 寫'aaa'記錄。但是，如果這個頁已經損壞了，對其進行重做是沒有意義的。這意味著，在修改頁前，必須有一個正確的頁的副本存在，當寫入失效發生時，先通過頁的副本還原該頁，再進行重做，這就是double write。
Double write由兩部分組成，一部分是內存中的 double write buffer。 另一部分是在物理磁盤上的共享表空間中的連續128個頁，大小和內存中（2M）一致。對緩沖池中的頁進行刷新時，並不直接寫磁盤，而是memcpy到double write buffer. 之後通過 double write buffer 分兩次，每次順序寫入共享表空間1M數據，然後馬上調用fsync同步磁盤。這個寫入因為共享表空間的double write頁是連續的，因此開銷不是很大。而完成 double write 頁的寫入後，再將double write buffer中的頁寫入各個表空間則是離散的寫入。
如果操作系統在將頁寫入磁盤的過程中發生了崩潰。那麼恢復時則可以從共享表空間中double write buffer頁找到該頁的副本。將其復制到表空間再應用重做日志。
自適應HASH索引
Innodb 存儲引擎會監控對表上各索引頁的查詢，如果觀察到建立hash索引可以帶來速度的提升。則建立hash索引，稱之為自適應hash索引（AHI).
AHI有一個要求，即對這個頁的連續訪問模式必須是一樣的. 例如（a, b)這樣的聯合索引，啟訪問模式可以使：
WHERE a = xxx
WHERE a = xxx and b = yyy
訪問模式一樣就是說查詢的條件一樣。如果交替執行上述的查詢操作。則不會建立AHI。
另外，AHI還要求以同一個模式訪問了100次，頁通過該模式訪問了N次，其中N = 頁中記錄 * 1/16
刷新鄰近頁
當刷新一個髒頁時，Innodb存儲引擎會通過檢測該頁所在區的所有頁，如果是髒頁，會一起進行刷新。
異步IO
Innodb 采用異步IO的方式來處理磁盤操作。
Check Point技術
為了避免數據丟失的問題，事物數據庫系統一般都采用了write ahead log策略。即事物提交時，先寫重做日志，再修改頁。
但是重做日志不可能無限增大，緩沖值（未刷新到磁盤的髒頁）也不可能無限大。即便真可以無限大，數據庫宕機後恢復時間也會很長。所以就需要 Check Point技術，該技術可以解決：
• 縮短數據庫恢復的時間；
• 緩沖池不夠用時，可以將髒頁刷新到磁盤；
• 重做日志不可用時（重做日志都是循環利用的），刷新髒頁到磁盤；
數據庫宕機後重啟時，不需要重做所有的日志了。因為 Check Point之前的頁都已經刷新到磁盤，數據庫只需對Check Point後的重做日志進行恢復即可。從而大大縮短恢復時間。
對於Innodb 而言，其實通過 LSN ( Log Sequence Number) 來比較版本的。 LSN 是一個8字節的數字。 每個頁有LSN， 重做日志有LSN， CheckPoint 也有LSN。可以通過下述命令觀察到
mysql> show engine innodb status\G; ............. Log sequence number 92561351052 Log flushed up to 92561351052 Last checkpoint at 92561351052
以上這篇InnoDb 體系架構和特性詳解 (Innodb存儲引擎讀書筆記總結)就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支持。
