關于MySQL對于后端程序員的重要性不言而喻，而InnoDB也已經是MySQL默認的存儲引擎。作為我們每天打交道的存儲引擎，我們對它可能需要對它有更多的了解。這樣對于很多靈異事件，才能從容應對。

[[281263]]

本次文章的內容大部分來自MySQL8.0的官方文檔，之所以沒有選擇現成的資料，而去挑戰自己的弱點——英語。是因為最近意識到，學習知識應該到知識的源頭，可能最開始會很吃力，但我相信對于后續的技術提升一定是有幫助的。與所有希望在技術上深挖的程序員同胞共勉~

簡介

首先來看官方文檔對InnoDB的解釋：

InnoDB是一個平衡了高可用和高性能的通用存儲引擎。

優勢

• 保護用戶數據：DML操作，通過事務來遵循ACID模型
• 高性能：行級鎖，一致性讀取
• 最小化主鍵查找的IO：聚簇索引
• 數據完整性：外鍵
• 崩潰恢復
• 在主內存緩存索引數據和緩存表
• 外鍵
• 校驗機制
• 只要你在設計表時選擇了合適的主鍵，主鍵列where、order by、group by、join操作會被自動優化
• 自適應哈希索引

InnoDB架構

InnoDB的整體架構可以分為兩個部分：內存架構、磁盤架構

InnoDB內存架構

InnoDB在內存中主要包括下面幾個部分：緩沖池、Change緩沖區、自適應哈希索引、Log緩沖區

【一】緩沖池

簡介： 存儲訪問時的緩存表和索引數據。在專用服務器上，通常會為緩沖池分配80%的物理內存

作用： 可以快速從內存獲取數據，加快了處理速度。

技術要點：

Page：為了high-volume的讀取效率，緩沖池進一步被分為頁的結構。

LRU：為了緩存的管理效率，緩沖池實現page間的鏈表，使用LRU算法。緩沖池使用調整后的LRU(最近最少使用)算法，當需求添加新的page時，最近最少使用的page被清除，同時新頁面被添加到鏈表的中間部分

這種中間點插入的策略，把鏈表分為兩個子鏈表

• 頭部：最近被訪問過的“年輕”頁
• 尾部：最近被訪問的old page

這樣使新子列表中保存更重要的page，舊子列表包含較少使用的page，這部分page是被清除的候選page

默認情況下，算法配置如下：

• 舊子列表：緩沖池的3/8
• midpoint(中間點)是新子列表尾部和舊子列表頭部的交界
• 當舊頁被訪問，會被移動到緩沖池的頭部，隨著數據庫的運行，一直沒有被訪問的頁會一直后移，直至最后被移除。

【二】Change Buffer

Change Buffer是一種特殊的數據結構，當某些頁面不在緩沖池中，緩存會改變二級索引page，這可能會造成insert，update，delete(DML)操作會與其他從緩沖池中的讀操作加載的page合并。

不同于聚簇索引，二級索引通常不唯一，同時二級索引的插入相對隨機。

同時，為了避免頻繁的IO隨機讀寫，當更新和刪除操作時，并不會立即寫入磁盤，而是會選擇系統空閑時定期進行寫入磁盤的操作。Change Buffer在內存中，是緩沖池中的一部分，在磁盤中，是系統表空間的一部分。

【三】自適應哈希索引

簡介： InnoDB可以基于搜索的模式，使用索引鍵前綴構建哈希索引，也就是說，這個哈希索引是由經常訪問的索引頁面構建的。

作用： 在不犧牲事務特性和可靠性的基礎上，使InnoDB像一個內存數據庫一樣工作，也就是說在一定情況下，通過這種哈希索引的方式會提升查詢速度。InnoDB中存在一種監視索引搜索的機制，但這種機制有時反倒帶來額外的開銷。所以在選擇是否使用哈希索引前，可能需要做好基準測試，否則還是建議禁用。

InnoDB磁盤架構

通過上面的整體架構圖可以看到，InnoDB在磁盤中存儲的信息包括：各種表空間(TableSpace)，Redo Log。

InnoDB對數據存儲方式的設計，主要是基于表空間的形式。表空間的種類如下圖所示：

使用InnoDB表的限制，來自MySQL官方文檔，感覺有些還是挺有趣的，但可能實際場景中并不會用到：

一個表最多包含1017列，表示并沒有創建過這樣多列的表

一個表最多可以創建64個二級索引

索引鍵前綴長度限制為3072字節

Undo Log 和 Redo Log

這里還有兩個Log區域需要關注一下：

Undo Log

Undo Log是與事務讀寫關聯的，主要作用在事務回滾和多版本并發控制中。

Undo Log在回滾段中存儲，回滾段在Undo表空間和全局臨時表空間中。Undo log被分為insert undo log 和update undo log。Insert undo log 只在事務回滾時需要，一旦事務提交就被丟棄。Update undo log 也被用在一致性讀，在一致性讀中可能需要update undo log的信息來生成該行數據早期的版本。

關于undo log的建議

定期地提交事務，包括哪些只包含一致性讀的事務，否則，InnoDB不會丟棄update undo log中的數據，回滾段會變得越來越大，占滿空間。undo log中回滾段的物理空間，通常小于相應插入或更新的行，可以利用這個信息計算回滾段需要的空間

Redo Log

也就是ib_logfile0和ib_logfile1兩個文件

這里結合的是MySQL的WAL(Write-Ahead Logging)也就是先寫日志，再寫磁盤，具體過程是下面這樣：當有一條記錄要更新，先將記錄寫到redo log，并更新內存，InnoDB會在空閑的時候，把操作記錄更新到磁盤。

官方建議的最佳實踐

• 指定主鍵
• 外鍵
• 關閉自動提交
• DML的事務進行分組
• 不要用lock table，如果希望某行的獨占寫，用 select … for update
• 啟用innode_file_per_table