關(guān)于MySQL對(duì)于后端程序員的重要性不言而喻，而InnoDB也已經(jīng)是MySQL默認(rèn)的存儲(chǔ)引擎。作為我們每天打交道的存儲(chǔ)引擎，我們對(duì)它可能需要對(duì)它有更多的了解。這樣對(duì)于很多靈異事件，才能從容應(yīng)對(duì)。

[[281263]]

本次文章的內(nèi)容大部分來(lái)自MySQL8.0的官方文檔，之所以沒(méi)有選擇現(xiàn)成的資料，而去挑戰(zhàn)自己的弱點(diǎn)——英語(yǔ)。是因?yàn)樽罱庾R(shí)到，學(xué)習(xí)知識(shí)應(yīng)該到知識(shí)的源頭，可能最開(kāi)始會(huì)很吃力，但我相信對(duì)于后續(xù)的技術(shù)提升一定是有幫助的。與所有希望在技術(shù)上深挖的程序員同胞共勉~

簡(jiǎn)介

首先來(lái)看官方文檔對(duì)InnoDB的解釋：

InnoDB是一個(gè)平衡了高可用和高性能的通用存儲(chǔ)引擎。

優(yōu)勢(shì)

• 保護(hù)用戶數(shù)據(jù)：DML操作，通過(guò)事務(wù)來(lái)遵循ACID模型
• 高性能：行級(jí)鎖，一致性讀取
• 最小化主鍵查找的IO：聚簇索引
• 數(shù)據(jù)完整性：外鍵
• 崩潰恢復(fù)
• 在主內(nèi)存緩存索引數(shù)據(jù)和緩存表
• 外鍵
• 校驗(yàn)機(jī)制
• 只要你在設(shè)計(jì)表時(shí)選擇了合適的主鍵，主鍵列where、order by、group by、join操作會(huì)被自動(dòng)優(yōu)化
• 自適應(yīng)哈希索引

InnoDB架構(gòu)

InnoDB的整體架構(gòu)可以分為兩個(gè)部分：內(nèi)存架構(gòu)、磁盤(pán)架構(gòu)

InnoDB內(nèi)存架構(gòu)

InnoDB在內(nèi)存中主要包括下面幾個(gè)部分：緩沖池、Change緩沖區(qū)、自適應(yīng)哈希索引、Log緩沖區(qū)

【一】緩沖池

簡(jiǎn)介： 存儲(chǔ)訪問(wèn)時(shí)的緩存表和索引數(shù)據(jù)。在專用服務(wù)器上，通常會(huì)為緩沖池分配80%的物理內(nèi)存

作用： 可以快速?gòu)膬?nèi)存獲取數(shù)據(jù)，加快了處理速度。

技術(shù)要點(diǎn)：

Page：為了high-volume的讀取效率，緩沖池進(jìn)一步被分為頁(yè)的結(jié)構(gòu)。

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

這種中間點(diǎn)插入的策略，把鏈表分為兩個(gè)子鏈表

• 頭部：最近被訪問(wèn)過(guò)的“年輕”頁(yè)
• 尾部：最近被訪問(wèn)的old page

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

默認(rèn)情況下，算法配置如下：

• 舊子列表：緩沖池的3/8
• midpoint(中間點(diǎn))是新子列表尾部和舊子列表頭部的交界
• 當(dāng)舊頁(yè)被訪問(wèn)，會(huì)被移動(dòng)到緩沖池的頭部，隨著數(shù)據(jù)庫(kù)的運(yùn)行，一直沒(méi)有被訪問(wèn)的頁(yè)會(huì)一直后移，直至最后被移除。

【二】Change Buffer

Change Buffer是一種特殊的數(shù)據(jù)結(jié)構(gòu)，當(dāng)某些頁(yè)面不在緩沖池中，緩存會(huì)改變二級(jí)索引page，這可能會(huì)造成insert，update，delete(DML)操作會(huì)與其他從緩沖池中的讀操作加載的page合并。

不同于聚簇索引，二級(jí)索引通常不唯一，同時(shí)二級(jí)索引的插入相對(duì)隨機(jī)。

同時(shí)，為了避免頻繁的IO隨機(jī)讀寫(xiě)，當(dāng)更新和刪除操作時(shí)，并不會(huì)立即寫(xiě)入磁盤(pán)，而是會(huì)選擇系統(tǒng)空閑時(shí)定期進(jìn)行寫(xiě)入磁盤(pán)的操作。Change Buffer在內(nèi)存中，是緩沖池中的一部分，在磁盤(pán)中，是系統(tǒng)表空間的一部分。

【三】自適應(yīng)哈希索引

簡(jiǎn)介： InnoDB可以基于搜索的模式，使用索引鍵前綴構(gòu)建哈希索引，也就是說(shuō)，這個(gè)哈希索引是由經(jīng)常訪問(wèn)的索引頁(yè)面構(gòu)建的。

作用： 在不犧牲事務(wù)特性和可靠性的基礎(chǔ)上，使InnoDB像一個(gè)內(nèi)存數(shù)據(jù)庫(kù)一樣工作，也就是說(shuō)在一定情況下，通過(guò)這種哈希索引的方式會(huì)提升查詢速度。InnoDB中存在一種監(jiān)視索引搜索的機(jī)制，但這種機(jī)制有時(shí)反倒帶來(lái)額外的開(kāi)銷。所以在選擇是否使用哈希索引前，可能需要做好基準(zhǔn)測(cè)試，否則還是建議禁用。

InnoDB磁盤(pán)架構(gòu)

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

InnoDB對(duì)數(shù)據(jù)存儲(chǔ)方式的設(shè)計(jì)，主要是基于表空間的形式。表空間的種類如下圖所示：

使用InnoDB表的限制，來(lái)自MySQL官方文檔，感覺(jué)有些還是挺有趣的，但可能實(shí)際場(chǎng)景中并不會(huì)用到：

一個(gè)表最多包含1017列，表示并沒(méi)有創(chuàng)建過(guò)這樣多列的表

一個(gè)表最多可以創(chuàng)建64個(gè)二級(jí)索引

索引鍵前綴長(zhǎng)度限制為3072字節(jié)

Undo Log 和 Redo Log

這里還有兩個(gè)Log區(qū)域需要關(guān)注一下：

Undo Log

Undo Log是與事務(wù)讀寫(xiě)關(guān)聯(lián)的，主要作用在事務(wù)回滾和多版本并發(fā)控制中。

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

關(guān)于undo log的建議

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

Redo Log

也就是ib_logfile0和ib_logfile1兩個(gè)文件

這里結(jié)合的是MySQL的WAL(Write-Ahead Logging)也就是先寫(xiě)日志，再寫(xiě)磁盤(pán)，具體過(guò)程是下面這樣：當(dāng)有一條記錄要更新，先將記錄寫(xiě)到redo log，并更新內(nèi)存，InnoDB會(huì)在空閑的時(shí)候，把操作記錄更新到磁盤(pán)。

官方建議的最佳實(shí)踐

• 指定主鍵
• 外鍵
• 關(guān)閉自動(dòng)提交
• DML的事務(wù)進(jìn)行分組
• 不要用lock table，如果希望某行的獨(dú)占寫(xiě)，用 select … for update
• 啟用innode_file_per_table