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

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

簡(jiǎn)介

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

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

優(yōu)勢(shì)

• 保護(hù)用戶數(shù)據(jù)：DML操作，通過事務(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)、磁盤架構(gòu)

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

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

【一】緩沖池

簡(jiǎn)介： 存儲(chǔ)訪問時(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è)子鏈表

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

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

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

• 舊子列表：緩沖池的3/8
• midpoint(中間點(diǎn))是新子列表尾部和舊子列表頭部的交界
• 當(dāng)舊頁(yè)被訪問，會(huì)被移動(dòng)到緩沖池的頭部，隨著數(shù)據(jù)庫(kù)的運(yù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ī)讀寫，當(dāng)更新和刪除操作時(shí)，并不會(huì)立即寫入磁盤，而是會(huì)選擇系統(tǒng)空閑時(shí)定期進(jìn)行寫入磁盤的操作。Change Buffer在內(nèi)存中，是緩沖池中的一部分，在磁盤中，是系統(tǒng)表空間的一部分。

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

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

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

InnoDB磁盤架構(gòu)

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

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

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

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

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

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

Undo Log 和 Redo Log

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

Undo Log

Undo Log是與事務(wù)讀寫關(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)也就是先寫日志，再寫磁盤，具體過程是下面這樣：當(dāng)有一條記錄要更新，先將記錄寫到redo log，并更新內(nèi)存，InnoDB會(huì)在空閑的時(shí)候，把操作記錄更新到磁盤。

網(wǎng)站欄目：你居然還不知道MySQL存儲(chǔ)引擎InnoDB分為內(nèi)存架構(gòu)、磁盤架構(gòu)？
網(wǎng)址分享：http://jinyejixie.com/news19/102919.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App設(shè)計(jì)、企業(yè)網(wǎng)站制作、用戶體驗(yàn)、微信小程序、響應(yīng)式網(wǎng)站、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)