1. InnoDB 體系架構
1.1 后臺執行緒
后臺執行緒的主要作用是負責重繪記憶體池中的資料，保證緩沖池中快取的是最近的資料，此外，還會將已修改的資料檔案重繪到磁盤檔案，同時保證在資料庫發生例外的情況下InnoDB能恢復到正常運行的狀態，
InnoDB存盤引擎是多執行緒的模型，其后臺有多個不同的后臺執行緒，負責處理不同的任務
1） Master thread
負責將緩沖池中的資料異步重繪到磁盤，保證資料的一致性，包括臟頁（由于磁盤的讀寫速度遠趕不上內核的讀寫速度，系統把讀寫頻繁的資料放在記憶體中，稱為高速快取，當行程修改了高速快取中的資料時，該頁被內核標為臟頁）的重繪、合并插入緩沖、undo頁的回收等，
Master thread具有最高執行緒優先級，內部由多個回圈（loop）組成：主回圈（loop）、后臺回圈（background loop）、重繪回圈（flush loop）、暫停回圈（suspend loop），Master Thread會根據資料庫運行狀態在不同回圈之間切換，其操作偽碼如下：
void master_thread(){ goto loop; loop: for(int i = 0; i<10; i++){ thread_sleep(1) // sleep 1 second do log buffer flush to disk // 日志緩沖重繪到磁盤 if (last_one_second_ios < 5% innodb_io_capacity(磁盤吞吐量)) // 當前一秒發生的IO次數 do merge 5% innodb_io_capacity insert buffer // 合并插入緩沖 if (buf_get_modified_ratio_pct (緩沖池中臟頁比例) > innodb_max_dirty_pages_pct) do buffer pool flush 100% innodb_io_capacity dirty page else if enable adaptive flush do buffer pool flush desired amount dirty page if ( no user activity ) goto background loop } if (last_ten_second_ios < innodb_io_capacity) do buffer pool flush 100% innodb_io_capacity dirty page do merge 5% innodb_io_capacity insert buffer do log buffer flush to disk do full purge // 洗掉無用的undo頁 對表進行update delete操作時，原先的行被標記為洗掉 // 由于一致性讀的關系需要保留這些行版本資訊，但在full purge時，會判斷 // 這些標記為洗掉的行是否可以洗掉（有時，會有查詢操作還需要讀之前版本的 // undo資訊） if ( buf_get_modified_ratio_pct > 70% ) do buffer pool flush 100% innodb_io_capacity dirty page else do buffer pool flush 10% innodb_io_capacity dirty page goto loop background loop: do full purge do merge 100% innodb_io_capacity insert buffer if not idle: goto loop: else: goto flush loop flush loop: do buffer pool flush 100% innodb_io_capacity dirty page if ( buf_get_modified_ratio_pct>innodb_max_dirty_pages_pct) goto flush loop goto suspend loop suspend loop: suspend_thread() waiting event goto loop; }
2） I/O thread
InnoDB存盤引擎中大量使用AIO（Async IO）來處理寫IO請求，以提高資料庫性能
3） Purge thread
事務提交后，所使用的undo log（用于事務回滾，將資料庫恢復到修改前的樣子，在第七章 事務會詳細介紹）可能不在需要了，因此需要Purge Thread來回收這些undo 頁
4） Page Cleaner thread
為了減輕Master Thread 的作業以及用戶查詢執行緒的阻塞，1,2.x版本將臟頁的重繪操作放到單獨的執行緒（Page Cleaner thread）來完成
1.2 記憶體
InnoDB記憶體資料物件
1） 緩沖池
InnoDB存盤引擎是基于磁盤存盤的，并將其中的記錄按照頁的方式進行管理，即基于磁盤的資料庫系統，
通常將部分或全部的頁備份到緩沖池（一塊記憶體區域）中，在讀取頁時，先判斷緩沖池中是否有需要的頁，如果有，稱為快取命中；否則，從磁盤中讀取相應的頁，
而對于資料庫中頁的修改，首先修改緩沖池中的頁，然后再通過checkpoint技術（本章第二節介紹）將頁重繪會磁盤中，
2） 緩沖池記憶體管理
LRU list
資料庫中的緩沖池通過LRU（least recently used）演算法進行管理，最頻繁使用的的頁在LRU串列的前端，最少使用的頁在尾端，當緩沖池不能存放新讀到的頁時，將首先釋放LRU串列中尾端的頁，InnoDB也對LRU演算法做了改進，新讀取到的頁放到了LRU串列的midpoint位置（距串列尾端3/8的位置），這是為了防止進行諸如索引或資料掃描等，需要訪問表中很多頁的操作，在插入到首部時，將原本的熱點資料擠出LRU串列，這種操作訪問的資料通常僅在本次查詢中用到，并非熱點資料，在下次查詢時，InnoDB需要再次訪問磁盤將熱點資料拷貝回緩沖池，
innodb_old_blocks_time用于表示頁讀取到mid位置后，需要多久才會被加入到LRU串列的熱端，當頁從LRU串列的old部分（midpoint之后的串列）加入到new部分時，稱為page made young.
Free list
資料庫剛啟動時，LRU串列是空的，這時頁都存在Free list中，當需要從緩沖池中分頁時，首先從Free list查找是否有可用的空閑頁，若有則將該頁從free list中洗掉，并放入到LRU list中，否則，根據LRU演算法，淘汰LRU串列末尾的頁，將該記憶體空間分配給新頁，
Flush list
flush list 用來管理將臟頁重繪回磁盤，
1.3 重做日志緩沖
存盤引擎一般先將重做日志資訊放到重做日志緩沖（redo log buffer），然后按一定頻率重繪到重做日志檔案：
- Master thread 每一秒將重做日志緩沖重繪到重做日志檔案
- 每個事務提交時會將重做日志緩沖重繪到重做日志檔案
- 當重做日志緩沖池剩余空間小于1/2時，將重做日志緩沖重繪到重做日志檔案
1.4 額外的記憶體池
緩沖池的幀緩沖還有對應的緩沖控制物件（記錄了LRU、鎖、等待等資訊）存盤在額外記憶體池中，在申請了很大的InnoDB緩沖池時，也應考慮相應增加額外記憶體池的大小
2. Checkpoint 技術
Checkpoint 技術解決以下幾個問題：
- 縮短資料庫恢復時間
- 緩沖池不夠用時，將臟頁重繪到磁盤
- 重做日志不可用時，重繪臟頁（事務資料庫普遍采用Write Ahead Log策略，先寫重做日志，再修改頁，避免宕機造成的資料丟失）
1） InnoDB存盤引擎確保LRU list有默認1024個頁可用，如果沒有，根據LRU演算法會溢位最近最少使用的頁，若此頁為臟頁，會執行checkpoint，將臟頁重繪回磁盤
2） 重做日志不可用的情況出現是因為當前事務資料庫系統對重做日志的設計都是回圈使用的，而不是允許其無限增大，當重做日志不可用時需要強制將一些頁重繪回磁盤
3） Master thread 中發生的checkpoint，每秒或每十秒從緩沖池中的臟頁串列重繪一定比例的頁回磁盤
4） 緩沖池中臟頁占75%時，強制進行checkpoint
3. InnoDB關鍵特性
3.1 插入緩沖 (insert buffer / change buffer(MySQL 5.5之后版本的叫法))
該部分內容亦參考了博客 https://blog.csdn.net/qq_36652619/article/details/89460786 http://mysql.taobao.org/monthly/2015/07/01/
插入聚集索引（clustered index）一般是順序的，不需要磁盤的隨機讀取，二級索引（secondary index，亦稱非聚集索引）通常不是唯一的，順序相對隨機，洗掉和更新可能會影響不在索引樹中相鄰的二級索引頁，
對于非聚集索引的插入或更新操作，不是每一次直接插入到索引頁中，而是先判斷插入的非聚集索引頁是否在緩沖池中，若在則直接插入；若不在，則先放入到一個Insert buffer物件中，以此減少二級索引的隨機IO，并達到操作合并的效果，Merge Insert/Change Buffer可能發生在以下幾種情況：
- 輔助索引頁被讀取到緩沖池中 （執行SELECT操作將頁緩沖到緩沖池中，需要檢查該輔助索引頁是否有記錄存放在Insert Buffer B+樹中，有則一次性更新操作到輔助索引頁中）
- Insert Buffer Bitmap 頁追蹤到該輔助索引頁已無可用空間（至少有1/32的可用空間）
- Master Thread （1.1 中master thread介紹過，每秒或每十秒進行一次merge insert buffer）
change buffer是一顆B+樹，ibuf btree通過三列(space id（每張表有唯一的ID）, page no（表中頁的偏移量）, counter)作為主鍵來唯一決定一條記錄，其中counter是一個遞增值，目的是為了維持不同操作的有序性，例如可以通過counter來保證在merge時執行如下序列時的循序和用戶操作順序是一致的：INSERT x, DELETE-MARK x, INSERT x
3.2 兩次寫
如果說Insert Buffer帶給InnoDB存盤引擎性能上的提升，doublewrite帶給InnoDB存盤引擎的是資料頁的可靠性，
但資料庫宕機時，可能InnoDB存盤引擎正在寫入某個頁到磁盤中，比如，16KB的頁，只寫了前4頁，之后就發生了宕機，這種情況稱為部分寫失效，
由上圖可知，doublewrite由兩部分組成，一部分是記憶體中的doublewrite buffer，大小為2MB，另一部分是物理磁盤上共享表空間中連續的128個頁，即兩個區，大小同樣為2MB，在對緩沖池的臟頁進行重繪時，并不直接寫磁盤，而是會通過memcpy函式將臟頁先復制到記憶體中的doublewrite buffer，之后通過doublewrite buffer分兩次，每次1MB順序寫入共享表空間的物理磁盤上（doublewrite頁是連續的，所以寫開銷并不是很大），在完成doublewrite頁的寫入后，再將doublewrite buffer中的頁寫入各個表空間檔案中，如果作業系統在將頁寫入磁盤的程序中發生了崩潰，在恢復的程序中，InnoDB存盤引擎可以從共享表空間中的doublewrite中找到該頁的一個副本，將其復制到表空間檔案，再應用重做日志，
3.3 自適應哈希索引
B+ 樹中，哈希查找的次數取決于B+樹的高度，InnoDB存盤引擎會監控表上各索引頁的查詢，并根據以下兩種情況建立自適應哈希索引（adaptive hash index）：
- 以某一模式連續訪問了100次
- 頁通過該模式訪問了N次，N=頁中記錄/16
需要注意的是，哈希索引只能用來搜索等值查詢，如 SELECT * FROM table WHERE index_col = XXX，不能用于范圍查詢，
3.4 異步IO
在同步I/O情況下，查詢執行緒將I/O請求放入佇列，innodb后臺執行緒會遍歷請求佇列，每次處理一個請求，并行處理的請求個數受到后臺執行緒的數量控制(引數innodb_read_io_threads)，AIO情況下，查詢執行緒直接將I/O請求分發給作業系統，從而避免的后臺執行緒數量對并發數的控制，innodb后臺執行緒只需要等待作業系統對IO請求的處理反饋資訊，另一個優點是IO Merge，即將多個IO合并為一個IO，例如：用戶訪問的頁（space，page_no）為：（8，6）、（8, 7）、（8，8），每個頁大小為16KB，同步IO需要進行3次IO操作，而AIO會判斷這三個頁是連續的，因此發送一個IO請求，從（8,6）開始，讀取48KB的頁，
Read ahead（預讀），臟頁的重繪（磁盤的寫入操作）都是通過AIO完成的，
3.5 重繪鄰接頁
當重繪一個臟頁時，InnoDB存盤引擎會檢測該頁所在區的所有頁，如果是臟頁，那么通過AIO一起進行重繪，但也存在兩個問題：
- 有些重繪到磁盤的臟頁，可能很快又變成臟頁
- 固態磁盤有著較高的IOPS（input/output operations per second），不太需要該特性（一般機械磁盤建議開啟該特性， innodb_flush_neighbors）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/296134.html
標籤：其他
下一篇：第三章 檔案（學習筆記）