后臺(tái)線程

•Master Thread

核心后臺(tái)線程，主要負(fù)責(zé)將緩沖池的數(shù)據(jù)異步刷新到磁盤(pán)。例如臟頁(yè)的刷新，插入緩沖的合并，undo 頁(yè)的回收等。

每秒一次的操作：

1.日志緩沖刷新到磁盤(pán)，即使該事務(wù)還沒(méi)有提交。該操作總是會(huì)發(fā)生，這個(gè)就是為了再大的事務(wù)，提交時(shí)間都很短。

2.當(dāng)IO壓力很小時(shí)（1s內(nèi)發(fā)生的IO次數(shù)小于5% innodb_io_capacity）合并5% innodb_io_capacity 的插入緩沖。

3.當(dāng)臟頁(yè)比例大于 innodb_max_dirty_pages_cnt, 刷新 innodb_io_capacity 個(gè)緩沖池中的臟頁(yè)到磁盤(pán)。否則如果 innodb_adaptive_flush 開(kāi)啟，則根據(jù)buf_flush_get_desired_flush_rate 來(lái)選擇合適刷新臟頁(yè)數(shù)量進(jìn)行刷新。

每10秒一次的操作：

1.如果過(guò)去10S 內(nèi)IO操作小于 innodb_io_capacity， 刷新 innodb_io_capacity 個(gè)緩沖池中的臟頁(yè)到磁盤(pán)。

2.合并5% innodb_io_capacity 個(gè)插入緩沖。

3.將日志緩沖刷新到磁盤(pán)。

4.刪除無(wú)用的undo頁(yè)。

5.如果緩沖池中臟頁(yè)比例超過(guò)70%，再次刷新 innodb_io_capacity 個(gè)臟頁(yè)到磁盤(pán)。否則刷新10% innodb_io_capacity 個(gè)臟頁(yè)。

background loop(數(shù)據(jù)庫(kù)空閑或者數(shù)據(jù)庫(kù)關(guān)閉時(shí)):

1.刪除無(wú)用的undo頁(yè)。

2.合并 innodb_io_capacity 個(gè)插入緩沖。

flush loop(數(shù)據(jù)庫(kù)空閑）：

1.刷新 innodb_io_capacity 個(gè)臟頁(yè)

•IO Thread

Innodb存儲(chǔ)引擎大量使用了AIO， IO Thread主要負(fù)責(zé)IO請(qǐng)求的回調(diào)。 可使用innodb_read_io_threads和innodb_write_io_threads參數(shù)列表調(diào)整。

•Purge Thread

事務(wù)提交后。該事務(wù)相關(guān)的undolog可能不再需要。Purge Thread就是用來(lái)回收不需要的undo頁(yè)的。

•PageCleaner Thread

負(fù)責(zé)臟頁(yè)的刷新操作。減輕master thread的工作以及對(duì)于用戶查詢線程的阻塞。

內(nèi)存緩沖池

對(duì)于數(shù)據(jù)庫(kù)中頁(yè)的修改操作，首先修改在緩沖池中的頁(yè)，然后再以一定的頻率刷新到磁盤(pán)上。這就意味著不是每次緩沖池中的頁(yè)修改時(shí)觸發(fā)刷新回磁盤(pán)，而是通過(guò)checkpoint技術(shù)刷新回磁盤(pán)。緩沖池的大小配置可通過(guò) innodb_buffer_pool_size來(lái)設(shè)置。

緩沖池的數(shù)據(jù)頁(yè)類(lèi)型有：數(shù)據(jù)頁(yè)，索引頁(yè)，undo頁(yè)，插入緩沖，自適應(yīng)哈希索引，innodb存儲(chǔ)的鎖信息，字典信息。

現(xiàn)在innodb存儲(chǔ)引擎允許多個(gè)緩沖池實(shí)例。這樣通過(guò)hash到不同緩沖池實(shí)例來(lái)減少鎖的競(jìng)爭(zhēng)。該參數(shù)可以通過(guò)innodb_buffer_pool_instance.

緩沖池是一個(gè)很大的內(nèi)存區(qū)域，數(shù)據(jù)庫(kù)通過(guò)LRU算法來(lái)進(jìn)行管理。但是因?yàn)榭紤]到全表掃描的操作。因此沒(méi)有采用樸素的LRU算法。LRU列表中加入的midpoint位置。新讀取到的頁(yè)，并不是直接放到lru列表的首部，而是midpoint位置。默認(rèn)情況下，在lru列表長(zhǎng)度的5/8處。由參數(shù)innodb_old_blocks_pct控制。

插入緩沖

對(duì)于非聚集索引的插入和更新操作，Innodb存儲(chǔ)引擎并不是直接插入到索引頁(yè)中，而是的Insert Buffer。然后再以一定的頻率進(jìn)行insertbuffer和輔助索引葉子節(jié)點(diǎn)的merge。著通常將多個(gè)隨機(jī)插入合并到一個(gè)操作中。大大提高了非聚集索引插入的性能。

Innodb使用 insertbuffer 條件：

•索引是非聚集索引

•索引不是unique的(如果是unique, 則又需查找索引來(lái)保證unique)

Insert Buffer 內(nèi)部實(shí)現(xiàn)

Insert Buffer 的數(shù)據(jù)結(jié)構(gòu)是一棵B+樹(shù)。 Mysql 4.1后，全局只有一棵B+樹(shù)，負(fù)責(zé)對(duì)所有表的輔助索引進(jìn)行insert Buffer. 并且，這棵樹(shù)存放在共享表空間里，默認(rèn)情況下即ibdata1。因此，如果僅通過(guò)獨(dú)立表空間ibd文件恢復(fù)表中數(shù)據(jù)時(shí)，可能會(huì)導(dǎo)致失敗。還需要通過(guò)insert buffer數(shù)據(jù)恢復(fù)表上的輔助索引。

Insert Buffer 的非葉節(jié)點(diǎn)存放的是查詢key, 構(gòu)造如 space(4字節(jié)） + marker（1字節(jié)） + offset（4字節(jié)）。space表示記錄所在表的表空間ID，offset表示頁(yè)的偏移量。marker用來(lái)兼容老版本。

Insert Buffer 葉子幾點(diǎn)構(gòu)造如 space + marker + offset + metadata + records。 space, marker, offset和前述意義相同。 metadata里的 IBUF_REC_OFFSET_COUNT保存了兩個(gè)字節(jié)的整數(shù)，用來(lái)排序記錄進(jìn)入 Insert Buffer 的順序。通過(guò)這個(gè)順序回訪呢個(gè)得到記錄的正確值。從Insert Buffer 葉子節(jié)點(diǎn)的第5列開(kāi)始，才是實(shí)際插入的各個(gè)記錄。

啟用 Insert Buffer索引后，輔助索引頁(yè)的記錄可能被插入到 Insert Buffer B+樹(shù)中。為了保證每次合并插入緩沖區(qū)成功， 必須要有一塊地方能標(biāo)記每個(gè)輔助索引頁(yè)的可用空間。 Insert Buffer采用一個(gè)特殊的頁(yè)來(lái)標(biāo)記，該頁(yè)的類(lèi)型為 Insert Buffer Bitmap。每個(gè) Insert Buffer Bitmap頁(yè)用來(lái)追蹤16384個(gè)頁(yè)，也就是256個(gè)區(qū)。每個(gè)Insert Buffer Bitmap 頁(yè)都在16384個(gè)頁(yè)的第二個(gè)頁(yè)。每個(gè)輔助索引頁(yè)在Bit map中占用4個(gè)字節(jié)，這里面主要用于表示輔助索引頁(yè)的可用數(shù)量。

合并插入緩沖

Insert Buffer中的記錄在以下情況下合并到真正的輔助索引中：

• 輔助索引頁(yè)被讀到緩沖池中；

• Insert Buffer Bitmap 頁(yè)追蹤到該輔助索引頁(yè)已無(wú)可用空間時(shí)；

• Master Thread調(diào)度時(shí)；

這樣子，對(duì)輔助索引頁(yè)的多次記錄操作通過(guò)一次操作合并到了原有的輔助索引頁(yè)中，從而提高性能。

兩次寫(xiě)（Double Write)

InsertBuffer 給 Innodb 存儲(chǔ)引擎帶來(lái)了性能的提升，而兩次寫(xiě)帶給 Innodb 存儲(chǔ)引擎的是數(shù)據(jù)頁(yè)的可靠性。

可能會(huì)有疑問(wèn)，如果發(fā)生寫(xiě)失敗，那么不是可以通過(guò)重做日志進(jìn)行恢復(fù)的嗎？這的確是一個(gè)辦法，但是必須知道，重做日志記錄的是頁(yè)的物理操作，如偏移量800， 寫(xiě)'aaa'記錄。但是，如果這個(gè)頁(yè)已經(jīng)損壞了，對(duì)其進(jìn)行重做是沒(méi)有意義的。這意味著，在修改頁(yè)前，必須有一個(gè)正確的頁(yè)的副本存在，當(dāng)寫(xiě)入失效發(fā)生時(shí)，先通過(guò)頁(yè)的副本還原該頁(yè)，再進(jìn)行重做，這就是double write。

Double write由兩部分組成，一部分是內(nèi)存中的 double write buffer。 另一部分是在物理磁盤(pán)上的共享表空間中的連續(xù)128個(gè)頁(yè)，大小和內(nèi)存中（2M）一致。對(duì)緩沖池中的頁(yè)進(jìn)行刷新時(shí)，并不直接寫(xiě)磁盤(pán)，而是memcpy到double write buffer. 之后通過(guò) double write buffer 分兩次，每次順序?qū)懭牍蚕肀砜臻g1M數(shù)據(jù)，然后馬上調(diào)用fsync同步磁盤(pán)。這個(gè)寫(xiě)入因?yàn)楣蚕肀砜臻g的double write頁(yè)是連續(xù)的，因此開(kāi)銷(xiāo)不是很大。而完成 double write 頁(yè)的寫(xiě)入后，再將double write buffer中的頁(yè)寫(xiě)入各個(gè)表空間則是離散的寫(xiě)入。

如果操作系統(tǒng)在將頁(yè)寫(xiě)入磁盤(pán)的過(guò)程中發(fā)生了崩潰。那么恢復(fù)時(shí)則可以從共享表空間中double write buffer頁(yè)找到該頁(yè)的副本。將其復(fù)制到表空間再應(yīng)用重做日志。

自適應(yīng)HASH索引

Innodb 存儲(chǔ)引擎會(huì)監(jiān)控對(duì)表上各索引頁(yè)的查詢，如果觀察到建立hash索引可以帶來(lái)速度的提升。則建立hash索引，稱(chēng)之為自適應(yīng)hash索引（AHI).

AHI有一個(gè)要求，即對(duì)這個(gè)頁(yè)的連續(xù)訪問(wèn)模式必須是一樣的. 例如（a, b)這樣的聯(lián)合索引，啟訪問(wèn)模式可以使：

WHERE a = xxx

WHERE a = xxx and b = yyy

訪問(wèn)模式一樣就是說(shuō)查詢的條件一樣。如果交替執(zhí)行上述的查詢操作。則不會(huì)建立AHI。

另外，AHI還要求以同一個(gè)模式訪問(wèn)了100次，頁(yè)通過(guò)該模式訪問(wèn)了N次，其中N = 頁(yè)中記錄 * 1/16

刷新鄰近頁(yè)

當(dāng)刷新一個(gè)臟頁(yè)時(shí)，Innodb存儲(chǔ)引擎會(huì)通過(guò)檢測(cè)該頁(yè)所在區(qū)的所有頁(yè)，如果是臟頁(yè)，會(huì)一起進(jìn)行刷新。

異步IO

Innodb 采用異步IO的方式來(lái)處理磁盤(pán)操作。

Check Point技術(shù)

為了避免數(shù)據(jù)丟失的問(wèn)題，事物數(shù)據(jù)庫(kù)系統(tǒng)一般都采用了write ahead log策略。即事物提交時(shí)，先寫(xiě)重做日志，再修改頁(yè)。

但是重做日志不可能無(wú)限增大，緩沖值（未刷新到磁盤(pán)的臟頁(yè)）也不可能無(wú)限大。即便真可以無(wú)限大，數(shù)據(jù)庫(kù)宕機(jī)后恢復(fù)時(shí)間也會(huì)很長(zhǎng)。所以就需要 Check Point技術(shù)，該技術(shù)可以解決：

• 縮短數(shù)據(jù)庫(kù)恢復(fù)的時(shí)間；

• 緩沖池不夠用時(shí)，可以將臟頁(yè)刷新到磁盤(pán)；

• 重做日志不可用時(shí)（重做日志都是循環(huán)利用的），刷新臟頁(yè)到磁盤(pán)；

數(shù)據(jù)庫(kù)宕機(jī)后重啟時(shí)，不需要重做所有的日志了。因?yàn)?Check Point之前的頁(yè)都已經(jīng)刷新到磁盤(pán)，數(shù)據(jù)庫(kù)只需對(duì)Check Point后的重做日志進(jìn)行恢復(fù)即可。從而大大縮短恢復(fù)時(shí)間。

對(duì)于Innodb 而言，其實(shí)通過(guò) LSN ( Log Sequence Number) 來(lái)比較版本的。 LSN 是一個(gè)8字節(jié)的數(shù)字。 每個(gè)頁(yè)有LSN， 重做日志有LSN， CheckPoint 也有LSN?？梢酝ㄟ^(guò)下述命令觀察到

mysql> show engine innodb status\G;

.............

Log sequence number 92561351052

Log flushed up to 92561351052

Last checkpoint at 92561351052

以上這篇InnoDb 體系架構(gòu)和特性詳解 (Innodb存儲(chǔ)引擎讀書(shū)筆記總結(jié))就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論