InnoDB 儲存引擎作為我們最常用到的儲存引擎之一，充分熟悉它的的實現和執行原理，有助於我們更好地建立和維護資料庫表。
InnoDB 體系架構
-
InnoDB 主要包括了： 記憶體池、後臺執行緒以及儲存檔案。
-
記憶體池又是由多個記憶體塊組成的，主要包括快取磁碟資料、
redo log緩衝等； -
後臺執行緒則包括了 ：
Master Thread、IO Thread以及Purge Thread等； -
由 InnoDB 儲存引擎實現的表的儲存結構檔案一般包括表結構檔案（.frm）、共享表空間檔案（ibdata1）、獨佔表空間檔案（ibd）以及日誌檔案（redo 檔案等）等。
1. 記憶體池
我們知道，如果客戶端從資料庫中讀取資料是直接從磁碟讀取的話，無疑會帶來一定的效能瓶頸，緩衝池的作用就是提高整個資料庫的讀寫效能。
客戶端讀取資料時，如果資料存在於緩衝池中， 客戶端就會直接讀取緩衝池中的資料，否則再去磁碟中讀取；對於資料庫中的修改資料，首先是修改在緩衝池中的資料，然後再通過 Master Thread 執行緒重新整理到磁碟上。
理論上來說，緩衝池的記憶體越大越好。 緩衝池中不僅快取索引頁和資料頁，還包括了 undo 頁，插入快取、自適應雜湊索引以及 InnoDB 地鎖資訊等等。
InnoDB 允許多個緩衝池例項，從而減少資料庫內部資源的競爭，增強資料庫的併發處理能力。
InnoDB 儲存引擎會先將重做日誌資訊放入到緩衝區中，然後再重新整理到重做日誌檔案中。
2. 後臺執行緒
Master Thread 主要負責將緩衝池中的資料非同步重新整理到磁碟中， 除此之外還包括插入快取、undo 頁的回收等，IO Thread 是負責讀寫 IO 的執行緒，而 Purge Thread 主要用於回收事務已經提交了的 undo log，Pager Cleaner Thread 是新引入的一個用於協助 Master Thread 重新整理髒頁到磁碟的執行緒，它可以減輕 Master Thread 的工作壓力，減少阻塞。
3. 儲存檔案
在 MySQL 中建立一張表都會生成一個.frm 檔案，該檔案是用來儲存每個表的後設資料資訊的，主要包含表結構定義。
在 InnoDB 中，儲存資料都是按表空間進行存放的，預設為共享表空間， 儲存的檔案即為共享表空間檔案（ibdata1）。若設定了引數 innodb_file_per_table 為 1，則會將儲存的資料、索引等資訊單獨儲存在一個獨佔表空間，因此也會產生一個獨佔表空間檔案（ibd）。如果你對共享表空間和獨佔表空間的理解還不夠透徹，接下來我會詳解。
而日誌檔案則主要是重做日誌檔案，主要記錄事務產生的重做日誌，保證事務的一致性。
InnoDB 邏輯儲存結構
InnoDB 邏輯儲存結構分為表空間（Tablespace）、段 (Segment)、區 (Extent)、頁 Page) 以及行 (row)。
1. 表空間（Tablespace）
InnoDB 提供了兩種表空間儲存資料的方式，一種是共享表空間，一種是獨佔表空間。 InnoDB 預設會將其所有的表資料儲存在一個共享表空間中，即 ibdata1。
我們可以通過設定 innodb_file_per_table 引數為 1（1 代表獨佔方式）開啟獨佔表空間模式。開啟之後，每個表都有自己獨立的表空間物理檔案，所有的資料以及索引都會儲存在該檔案中，這樣方便備份以及恢復資料。
2. 段 (Segment)
表空間是由各個段組成的，段一般分為資料段、索引段和回滾段等。我們知道，InnoDB 預設是基於 B + 樹實現的資料儲存。
這裡的索引段則是指的 B + 樹的非葉子節點，而資料段則是 B + 樹的葉子節點。而回滾段則指的是回滾資料。
3. 區 (Extent) / 頁（Page）
區是表空間的單元結構，每個區的大小為 1MB。而頁是組成區的最小單元， 頁也是 InnoDB 儲存引擎磁碟管理的最小單元，每個頁的大小預設為 16KB。為了保證頁的連續性，InnoDB 儲存引擎每次從磁碟申請 4-5 個區。
4. 行（Row）
InnoDB 儲存引擎是面向列的（row-oriented)，也就是說資料是按行進行存放的，每個頁存放的行記錄也是有硬性定義的，最多允許存放 16KB/2-200 行，即 7992 行記錄。
InnoDB 事務之 redo log 工作原理
InnoDB 是一個事務性的儲存引擎， 而 InnoDB 的事務實現是基於事務日誌 redo log 和 undo log 實現的。redo log 是重做日誌，提供再寫入操作，實現事務的永續性；undo log 是回滾日誌，提供回滾操作，保證事務的一致性。
redo log 又包括了記憶體中的日誌緩衝（redo log buffer） 以及儲存在磁碟的重做日誌檔案（redo log file），前者儲存在記憶體中，容易丟失，後者持久化在磁碟中，不會丟失。
InnoDB 的更新操作採用的是 Write Ahead Log 策略，即先寫日誌，再寫入磁碟。 當一條記錄更新時，InnoDB 會先把記錄寫入到 redo log buffer 中，並更新記憶體資料。我們可以通過引數
innodb_flush_log_at_trx_commit 自定義 commit 時，如何將 redo log buffer 中的日誌重新整理到 redo log file 中。
在這裡，我們需要注意的是 InnoDB 的 redo log 的大小是固定的， 分別有多個日誌檔案採用迴圈方式組成一個迴圈閉環，當寫到結尾時，會回到開頭迴圈寫日誌。我們可以通過引數 innodb_log_files_in_group 和 innodb_log_file_size 配置日誌檔案數量和每個日誌檔案的大小。
Buffer Pool 中更新的資料未重新整理到磁碟中，該記憶體頁我們稱之為髒頁。 最終髒頁的資料會重新整理到磁碟中，將磁碟中的資料覆蓋，這個過程與 redo log 不一定有關係。
只有當 redo log 日誌滿了的情況下，才會主動觸發髒頁重新整理到磁碟， 而髒頁不僅只有 redo log 日誌滿了的情況才會重新整理到磁碟，以下幾種情況同樣會觸發髒頁的重新整理：
- 系統記憶體不足時，需要將一部分資料頁淘汰掉，如果淘汰的是髒頁，需要先將髒頁同步到磁碟；
- MySQL 認為空閒的時間，這種情況沒有效能問題；
- MySQL 正常關閉之前，會把所有的髒頁刷入到磁碟，這種情況也沒有效能問題。
在生產環境中，如果我們開啟了慢 SQL 監控，你會發現偶爾會出現一些用時稍長的 SQL。 這是因為髒頁在重新整理到磁碟時可能會給資料庫帶來效能開銷，導致資料庫操作抖動。
LRU 淘汰策略
以上我們瞭解了 InnoDB 的更新和插入操作的具體實現原理，接下來我們再來了解下它的實現和優化方式。
InnoDB 儲存引擎是基於集合索引實現的資料儲存，也就是除了索引列以及主鍵是儲存在 B + 樹之外， 其它列資料也儲存在 B + 樹的葉子節點中。而這裡的索引頁和資料頁都會快取在緩衝池中，在查詢資料時，只要在緩衝池中存在該資料，InnoDB 就不用每次都去磁碟中讀取頁，從而提高資料庫的查詢效能。
雖然緩衝池是一個很大的記憶體區域，但由於存放了各種型別的資料， 加上儲存資料量之大，緩衝池無法將所有的資料都儲存在其中。因此，緩衝池需要通過 LRU 演算法將最近且經常查詢的資料快取在其中，而不常查詢的資料就淘汰出去。
InnoDB 對 LRU 做了一些優化， 我們熟悉的 LRU 演算法通常是將最近查詢的資料放到 LRU 列表的首部，而 InnoDB 則是將資料放在一個 midpoint 位置，通常這個 midpoint 為列表長度的 5/8。
這種策略主要是為了避免一些不常查詢的操作突然將熱點資料淘汰出去，而熱點資料被再次查詢時，需要再次從磁碟中獲取，從而影響資料庫的查詢效能。
如果我們的熱點資料比較多，我們可以通過調整 midpoint 值來增加熱點資料的儲存量，從而降低熱點資料的淘汰率。
總結
以上 InnoDB 的實現和執行原理到這裡就介紹完了。 總的來講，作為開發工程師，我們應該掌握資料庫幾個大的知識點，然後再深入到資料庫內部實現的細節，這樣才能避免經常寫出一些具有效能問題的 SQL，培養調優資料庫效能的能力。
看完三件事❤️
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
- 點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。
- 關注公眾號 『 阿風的架構筆記 』，不定期分享原創知識。
- 同時可以期待後續文章ing?
- 關注後回覆【666】掃碼即可獲取架構進階學習資料包