mysql的一個(gè)update需要經(jīng)歷什么最終持久化到磁盤？

我們執(zhí)行一個(gè)普通的update語(yǔ)句時(shí)钠至，mysql底層會(huì)做些什么最終將數(shù)據(jù)持久化到磁盤呢葛虐？

疑問(wèn)？

mysql中執(zhí)行更新操作時(shí)棉钧，必然涉及到讀屿脐、寫內(nèi)存、寫磁盤的操作流程宪卿。mysql是通過(guò)什么樣的操作去完成更新流程的優(yōu)化的诵？

1. update語(yǔ)句執(zhí)行流程

update T set c = c+1 where id = 2;
  1. 執(zhí)行器先調(diào)用存儲(chǔ)引擎的接口獲取“id=2”的數(shù)據(jù)行。如果這一行所在的數(shù)據(jù)頁(yè)在內(nèi)存中佑钾，則存儲(chǔ)引擎直接返回給執(zhí)行器西疤；否則需要存儲(chǔ)引擎先去磁盤中獲取數(shù)據(jù)，讀取到內(nèi)存中休溶，然后再返回代赁。
  2. 執(zhí)行器拿到存儲(chǔ)引擎返回的這行數(shù)據(jù)，對(duì)其進(jìn)行更新操作兽掰，將c的值加+1芭碍，得到新的數(shù)據(jù)，在調(diào)用存儲(chǔ)引擎接口禾进，寫入這行數(shù)據(jù)豁跑。
  3. 存儲(chǔ)引擎收到執(zhí)行器寫入的這行數(shù)據(jù)的新結(jié)果廉涕，先將這條更新記錄保存在內(nèi)存（Buffer Pool）中泻云，并將這條更新記錄寫入redo log Buffer艇拍，更新redo log的狀態(tài)為prepare，隨后向執(zhí)行器返回結(jié)果宠纯。
  4. 執(zhí)行器知道存儲(chǔ)引擎已經(jīng)將這條更新記錄成功寫入redo log Buffer（內(nèi)存）后卸夕。
  5. 當(dāng)SQL事務(wù)提交時(shí)，redo log 調(diào)用fsync寫入磁盤（默認(rèn)策略是事務(wù)提交寫入磁盤）婆瓜。
  6. 當(dāng)SQL事務(wù)提交時(shí)快集，binlog調(diào)用fsync寫入磁盤（默認(rèn)策略是事務(wù)提交寫入磁盤）。
  7. 在執(zhí)行器寫入binlog成功后廉白，存儲(chǔ)引擎將redo log的狀態(tài)更新為commit个初，此時(shí)才算SQL事務(wù)正在提交成功；
redo log日志.png

2. redo log詳解

2.1 為什么要引入redo log

為了減少與磁盤的IO交互猴蹂，在對(duì)數(shù)據(jù)庫(kù)增改刪操作時(shí)院溺，實(shí)際主要都是針對(duì)內(nèi)存里的Buffer Pool中的數(shù)據(jù)進(jìn)行的。

最詳細(xì)的MySQL事務(wù)特性及原理講解０跚帷（一）
理解Mysql中的Buffer pool

InnoDB作為mysql的存儲(chǔ)引擎珍逸，數(shù)據(jù)是存放在磁盤中的，但是每次讀寫數(shù)據(jù)需要磁盤IO聋溜，效率就很低谆膳。為此，InnoDB提供了緩存（Buffer Pool）撮躁，Buffer Pool中包含了磁盤中部分?jǐn)?shù)據(jù)頁(yè)的映射漱病，作為訪問(wèn)數(shù)據(jù)庫(kù)的緩沖：

數(shù)據(jù)庫(kù)執(zhí)行流程.png
  1. 讀取數(shù)據(jù)時(shí)，首先從Buffer Pool中讀取把曼，如果Buffer Pool中沒(méi)有缨称，則加載磁盤中的數(shù)據(jù)到Buffer Pool中；
  2. 寫入數(shù)據(jù)的時(shí)候祝迂，會(huì)首先寫入Buffer Pool睦尽，Buffer Pool中修改的數(shù)據(jù)會(huì)定期刷新到磁盤（這一過(guò)程被稱為刷臟）。

Buffer Pool的使用大大提高了讀寫數(shù)據(jù)的效率型雳，但是也帶來(lái)了新的問(wèn)題：如果mysql宕機(jī)当凡，如何保證數(shù)據(jù)不丟失？

2.2 redo log如何保證數(shù)據(jù)不丟失纠俭？

在修改數(shù)據(jù)時(shí)沿量，除了修改Buffer Pool中的數(shù)據(jù)，還會(huì)在redo log Buffer(內(nèi)存)記錄這次操作冤荆。當(dāng)事務(wù)提交時(shí)朴则，會(huì)調(diào)用fsync對(duì)redo log（磁盤）進(jìn)行刷盤。重啟時(shí)可以讀取磁盤上的redo log中的數(shù)據(jù)钓简，對(duì)數(shù)據(jù)庫(kù)進(jìn)行恢復(fù)乌妒。redo log采用的是WAL技術(shù)（Write-ahead logging汹想，預(yù)寫式日志）。

2.3 WAL技術(shù)撤蚊？

2.3.1 簡(jiǎn)介

目的：傳統(tǒng)磁盤的順序訪問(wèn)性能遠(yuǎn)好于隨機(jī)訪問(wèn)古掏，利用順序?qū)慙og來(lái)記錄對(duì)數(shù)據(jù)庫(kù)的操作，并在故障恢復(fù)后通過(guò)Log恢復(fù)數(shù)據(jù)庫(kù)到正確的狀態(tài)侦啸；
算法：采用的是ARIES算法來(lái)實(shí)現(xiàn)槽唾，Log同時(shí)記錄的是Redo和Undo的信息。原因就是BufferPool可以采用steal/no force的方式進(jìn)行刷盤光涂。

2.3.2 簡(jiǎn)述

由于傳統(tǒng)磁盤順序訪問(wèn)性能遠(yuǎn)好于隨機(jī)訪問(wèn)庞萍，采用Logging的故障恢復(fù)機(jī)制意圖利用順序?qū)懙腖og來(lái)記錄對(duì)數(shù)據(jù)庫(kù)的操作，并在故障恢復(fù)后通過(guò)Log內(nèi)容將數(shù)據(jù)庫(kù)恢復(fù)到正確的狀態(tài)忘闻。簡(jiǎn)單來(lái)說(shuō)挂绰，每次修改內(nèi)容前先順序?qū)憣?duì)應(yīng)的log，同時(shí)為了保證恢復(fù)時(shí)可以從Log中看到最新的數(shù)據(jù)庫(kù)狀態(tài)服赎，要求Log先于數(shù)據(jù)內(nèi)容落盤葵蒂，也就是常說(shuō)的Write Ahead Log，WAL重虑。

除此之外践付，事務(wù)完成Commit前還需要在Log中記錄對(duì)應(yīng)的Commit標(biāo)記，以便恢復(fù)是了解當(dāng)時(shí)的事務(wù)狀態(tài)缺厉，因此還需要關(guān)注Commit標(biāo)記和事務(wù)中數(shù)據(jù)落盤順序永高。根據(jù)Log中記錄的內(nèi)容可以分為三類：Undo-Only、Redo-Only提针、Redo-Undo命爬。

1、Undo Only Logging

Redo Log中記錄Log記錄可以表示為<T,X,v>：事務(wù)T修改了X的值辐脖，X的舊值是v饲宛。
事務(wù)提交時(shí)，需要強(qiáng)制Flush（將BufferPool的數(shù)據(jù)落盤）嗜价。以此保證Commit標(biāo)記落盤前艇抠，對(duì)應(yīng)事務(wù)的所有數(shù)據(jù)落盤，
落盤順序：Log記錄->Data->Commit標(biāo)記久锥。恢復(fù)時(shí)可以根據(jù)Commit標(biāo)記判斷事務(wù)的狀態(tài)家淤，并通過(guò)Undo Log中記錄的舊值將未提交事務(wù)的修改回滾。

  • Durability of Updates（持久性保證）：Data強(qiáng)制刷盤瑟由，已經(jīng)Commit的事務(wù)由于Data都已經(jīng)在Commit標(biāo)記前落盤絮重，因此會(huì)一直存在；
  • Failure Atomic（原子性保證）：Undo log內(nèi)容保證，失敗事務(wù)的已刷盤的修改會(huì)在恢復(fù)階段通過(guò)Undo log日志回滾青伤，不在可見(jiàn)督怜。

Undo-Only不能解決Page內(nèi)并發(fā)的事務(wù)，例如兩個(gè)事務(wù)的修改落到一個(gè)Page中潮模，一個(gè)事務(wù)提交前需要強(qiáng)制Flush操作，會(huì)導(dǎo)致同Page所有事務(wù)的Data落盤痴施，可能會(huì)早于對(duì)應(yīng)的Log項(xiàng)從而損害WAL擎厢，同時(shí)也會(huì)導(dǎo)致關(guān)鍵路徑上過(guò)于頻繁的磁盤隨機(jī)訪問(wèn)。

注：BufferPool的刷盤策略采用的是force辣吃；

2. Redo-Only Logging

不同于Undo-Only动遭，采用Redo-Only的Log記錄的是修改后的新值。對(duì)應(yīng)的神得，Commit需要保證：Log中的Commit標(biāo)記在事務(wù)的任何數(shù)據(jù)之前落盤厘惦，即落盤順序：Log記錄->Commit標(biāo)記->Data×ú荆恢復(fù)時(shí)同樣根據(jù)Commit標(biāo)記判斷事務(wù)狀態(tài)宵蕉，并通過(guò)Redo log中新值將已經(jīng)Commit但是沒(méi)有落盤的事務(wù)修改重放。

  • Durability of Updates（持久性保證）：Redo log內(nèi)容保證节榜，已提交事務(wù)但未刷盤的修改羡玛，利用Redo log中的內(nèi)容重放，之后可見(jiàn)宗苍；
  • Failure Atomic（原子性保證）：阻止Commit前Data落盤保證稼稿，失敗事務(wù)的修改不會(huì)出現(xiàn)在磁盤上，自然不可見(jiàn)讳窟。

Redo-Only同樣不能有Page內(nèi)并發(fā)問(wèn)題让歼，Page中多個(gè)不同事務(wù)，只要有一個(gè)未提交就不能刷盤丽啡，這些數(shù)據(jù)全部都要維護(hù)在內(nèi)存中谋右，造成較大的內(nèi)存壓力。

3. Redo-Undo Logging

可以看出只有Undo或者Redo問(wèn)題补箍，主要來(lái)自對(duì)Commit標(biāo)記以及Data落盤順序的限制倚评，而這種限制來(lái)源于：Log信息中對(duì)新值或舊值的缺失。因此Redo-Undo采用同時(shí)記錄新值和舊值方式馏予，來(lái)消除Commit和Data之間刷盤順序的限制天梧。

  • Durability of Updates（持久性保證）：Redo log內(nèi)容保證，已提交事務(wù)但未刷盤的修改霞丧，利用Redo log中的內(nèi)容重放呢岗，之后可見(jiàn)；
  • Failure Atomic（原子性保證）：Undo log內(nèi)容保證，失敗事務(wù)的已刷盤的修改會(huì)在恢復(fù)階段通過(guò)Undo log日志回滾后豫，不在可見(jiàn)悉尾。

如此一來(lái)：同Page的不同事務(wù)提交會(huì)變得非常簡(jiǎn)單。同時(shí)可以將連續(xù)的數(shù)據(jù)攢著進(jìn)行批量刷盤已利用磁盤較高的順序讀寫能力挫酿。

2.3.3 BufferPool的Force和Steal

從上面看出：Redo和Undo內(nèi)容分別可以保證Durability和Atomic兩個(gè)特性构眯，其中一種信息的缺失需要用嚴(yán)格的刷盤順序來(lái)彌補(bǔ)。這里關(guān)注刷盤順序包含兩個(gè)維度：

  • Force or No-Force：Commit時(shí)是否需要強(qiáng)制刷盤早龟，采用Force的方式由于所有已提交事務(wù)數(shù)據(jù)一定已經(jīng)存在于磁盤惫霸，自然而然地保證了Durability；
  • No-Steal or Steal：Commit前數(shù)據(jù)能否提前刷盤葱弟，采用No-Steal的方式由于保證事務(wù)提交前修改不會(huì)出現(xiàn)在磁盤上壹店，自然而然保證了Atomic。

總結(jié)一下芝加，實(shí)現(xiàn)Durability可以通過(guò)記錄Redo信息或要求Force刷盤順序硅卢，實(shí)現(xiàn)Atomic需要記錄Undo信息或要求No-Steal刷盤順序，組合得到如下四種模式藏杖，如下圖所示：

image.png

2.3.4 ARIES算法

InnoDB采用的ARIES算法将塑，ARIES本質(zhì)是一種Redo-Undo的WAL實(shí)現(xiàn)。

Normal過(guò)程：

  1. 修改數(shù)據(jù)之前先追加Log記錄蝌麸，Log內(nèi)容同時(shí)包括Redo和Undo信息抬旺，每個(gè)日志記錄產(chǎn)生LSN（Log Sequence Number），來(lái)標(biāo)記日志中的位置祥楣；
  2. 數(shù)據(jù)Page記錄最后修改的日志項(xiàng)LSN开财，以此判斷Page中內(nèi)容的新舊程度，實(shí)現(xiàn)冪等误褪。
  3. 故障恢復(fù)階段需要通過(guò)Log中的內(nèi)容恢復(fù)數(shù)據(jù)庫(kù)狀態(tài)责鳍，為了減少恢復(fù)時(shí)需要處理的日志量，ARIES會(huì)在正常運(yùn)行期間周期性的生成Checkpoint兽间，Checkpoint中除了當(dāng)前日志LSN外历葛，還需要記錄當(dāng)前活躍事務(wù)的最新LSN，以及所有臟頁(yè)嘀略，供恢復(fù)時(shí)決定重放Redo的開(kāi)始位置恤溶。需要注意的是：由于生成checkpoint時(shí)數(shù)據(jù)庫(kù)還在正常提供服務(wù)（Fuzzy checkpoint），其中記錄的活躍事務(wù)以及Dirty Page信息不一定準(zhǔn)確帜羊，因此需要Recovery階段通過(guò)Log內(nèi)容進(jìn)行修正咒程。

為什么需要checkpoint？

WAL有一個(gè)顯著的問(wèn)題讼育，隨著系統(tǒng)運(yùn)行時(shí)間越長(zhǎng)帐姻，log會(huì)變得越來(lái)越長(zhǎng)稠集，導(dǎo)致每次crash之后，dbms需要對(duì)整個(gè)log進(jìn)行恢復(fù)操作饥瓷，所以dbms定期會(huì)做checkpoint剥纷，將當(dāng)前在內(nèi)存中所有數(shù)據(jù)全部刷到磁盤，則下次恢復(fù)只需要從最新的checkpoint開(kāi)始即可晦鞋。

Recover過(guò)程：
故障恢復(fù)包括三個(gè)階段：Analysis，Redo和Undo渔肩。

  1. Analysis：主要是利用Checkpoint及Log中的信息確認(rèn)后續(xù)Redo和Undo階段的操作范圍，通過(guò)Log修正Checkpoint中記錄的Dirty Page集合信息，并用其中涉及最小的LSN位置作為下一步Redo的開(kāi)始位置RedoLSN钳踊。同時(shí)修正Checkpoint中記錄的活躍事務(wù)集合（未提交事務(wù)），作為Undo過(guò)程的回滾對(duì)象；
  2. Redo階段：從Analysis獲得的RedoLSN出發(fā)，重放所有的Log中的Redo內(nèi)容，注意這里也包含了未Commit事務(wù)柏锄；
  3. Undo階段對(duì)所有未提交事務(wù)利用Undo信息進(jìn)行回滾缔御，通過(guò)Log的PrevLSN可以順序找到事務(wù)所有需要回滾的修改。

數(shù)據(jù)庫(kù)故障恢復(fù)機(jī)制的前世今生

ARIES Recovery 算法

2.4 redo log也是寫磁盤，比BufferPool寫入磁盤優(yōu)點(diǎn)是什么？

redo log也需要在事務(wù)提交時(shí)（默認(rèn)策略）將日志寫入磁盤，但是它要比Buffer Pool中修改的數(shù)據(jù)寫入磁盤（即刷臟）要快：

  1. 刷臟是隨機(jī)IO，每次修改數(shù)據(jù)位置都是隨機(jī)，寫redo log是追加操作，屬于順序IO北救；
  2. 刷臟是以數(shù)據(jù)頁(yè)（Page）為單位，Mysql默認(rèn)頁(yè)大小為16KB拐迁，一個(gè)Page上一個(gè)小修改都要整頁(yè)寫入多矮，而redo log中是精簡(jiǎn)的日志數(shù)據(jù)湾盗，無(wú)效IO大大減少匀借。

2.5 redo log刷盤規(guī)則

當(dāng)事務(wù)提交時(shí)是鬼，需要先將事務(wù)日志寫入redo log Buffer中，這些寫入redo log Buffer的日志并不是隨著事務(wù)的提交立刻刷新到redo log 文件中芒率，而是有一定的規(guī)則囤耳，從而保證了 Redo Log 文件中數(shù)據(jù)的持久性。這種刷盤規(guī)則可以由innodb_flush_log_at_trx_commit變量控制偶芍，它的取值：

  • 0：每次提交事務(wù)時(shí)充择，不會(huì)將 Log Buffer 中的日志寫入 OS buffer, 而是通過(guò)一個(gè)單獨(dú)的線程，每秒寫入 OS buffer 并調(diào)用系統(tǒng)的 fsync() 函數(shù)寫入磁盤的 Redo Log File, 這種方式不是實(shí)時(shí)寫磁盤的匪蟀， 而是每隔 1s 寫一次日志椎麦，如果系統(tǒng)崩潰，可能會(huì)丟失 1s 的數(shù)據(jù)材彪。
  • 1（默認(rèn)）：每次提交事務(wù)都會(huì)將 Log Buffer 中的日志寫入 OS buffer 中观挎，并且會(huì)調(diào)用 fsync() 函數(shù)將日志寫入 Redo Log File 中琴儿，這種方式雖然不會(huì)再崩潰時(shí)丟失數(shù)據(jù)，但是性能比較差嘁捷。也是這個(gè)變量的默認(rèn)值造成。
  • 2：每次提交事務(wù)時(shí)，都只是將數(shù)據(jù)寫入 os buffer 中雄嚣，之后每隔 1s ,通過(guò) fsync() 函數(shù)將 os buffer 中的數(shù)據(jù)寫入 Redo Log 文件中谜疤。

來(lái)源：Redo Log 刷盤策略

2.6 Redo 的整體流程

mysql_redo.png
  1. 先將原始數(shù)據(jù)從磁盤中讀入到內(nèi)存（Buffer Pool）中，修改內(nèi)存拷貝现诀；
  2. 生成redo log并寫入redo log buffer（內(nèi)存）夷磕，記錄的是數(shù)據(jù)被修改后的值；
  3. 當(dāng)事務(wù)commit時(shí)仔沿，將redo log中的內(nèi)容刷新到redo log file（磁盤）坐桩，對(duì)redo log file采用追加寫的方式；
  4. 定期將內(nèi)存（Buffer Pool）中修改的值刷新到磁盤封锉；

2.7 redo log的兩階段提交

redo log 采用是兩階段提交的方式最終commit绵跷，那么為什么采用兩階段提交的方式？

看上面的流程圖成福，mysql在寫redo log兩階段變更時(shí)會(huì)寫bin log日志表碾局。而記錄binlog日志的目的：既可以用于數(shù)據(jù)恢復(fù)、binlog數(shù)據(jù)監(jiān)聽(tīng)奴艾、主從庫(kù)同步净当。那么redo log表采用兩階段提交的目的在于：保證binlog 和redo log文件的一致性。

若不采用兩階段提交：

  1. 先寫redo log在寫binlog

如果引擎寫完redo log后蕴潦，bin log還沒(méi)有寫像啼。異常重啟。主庫(kù)使用redo log 日志將數(shù)據(jù)恢復(fù)潭苞。但binlog沒(méi)有記錄這個(gè)語(yǔ)句忽冻，那么從庫(kù)根據(jù)binlog同步數(shù)據(jù)時(shí)依舊沒(méi)有這條語(yǔ)句，造成了主從庫(kù)的數(shù)據(jù)不一致性此疹；

  1. 先寫binlog在寫redo log

寫完binlog后異常重啟僧诚，因?yàn)閞edo log沒(méi)有些，主庫(kù)恢復(fù)后沒(méi)有這條事務(wù)蝗碎。但是由于binlog中有這條記錄湖笨，從庫(kù)根據(jù)binlog日志同步數(shù)據(jù)時(shí)，也會(huì)有這條事務(wù)衍菱。依舊導(dǎo)致主從不一致赶么。

3. redo log 和binlog

3.1 redo log和binlog的區(qū)別

  1. redo log是InnoDB存儲(chǔ)引擎層面，而binlog是mysql server層面脊串，所有存儲(chǔ)引擎均可使用辫呻；
  2. redo log是InnoDB為了解決crash safe（系統(tǒng)崩潰后恢復(fù)）清钥，而binlog是定期存檔，重要的作用是支持主從同步放闺。
  3. redo log是循環(huán)寫祟昭，空間滿時(shí)就會(huì)發(fā)生寫覆蓋；binlog是追加寫怖侦，不會(huì)覆蓋篡悟。
  4. bin log屬于邏輯日志，因?yàn)闆](méi)有涉及在具體哪一個(gè)page上進(jìn)行修改匾寝；redo log屬于物理邏輯日志（Physiological Logging）搬葬，雖然有很多人認(rèn)為其屬于物理日志。

邏輯日志與物理日志

3.2 為什么redo log具有crash-safe能力艳悔，而binlog沒(méi)有

redo log：是一個(gè)固定大小急凰，“循環(huán)寫”的日志文件，記錄物理邏輯日志猜年；
binlog：是一個(gè)無(wú)限大小抡锈，“追加寫”的日志文件，記錄的是邏輯日志乔外；

redo log只會(huì)記錄未刷盤的日志床三，已經(jīng)刷入磁盤的數(shù)據(jù)都會(huì)從redo log這個(gè)固定大小的日志文件里刪除；binlog是追加日志杨幼，保存的是全量的日志撇簿。

當(dāng)數(shù)據(jù)庫(kù)crash崩潰后，想要恢復(fù)：未刷盤但已經(jīng)寫入redo log和binlog的數(shù)據(jù)到內(nèi)存時(shí)推汽，binlog是無(wú)法實(shí)現(xiàn)的补疑。雖然binlog擁有全量日志歧沪，但是沒(méi)有標(biāo)志讓InnoDB判斷哪些數(shù)據(jù)已經(jīng)刷盤歹撒。

但redo log不一樣，只要寫入磁盤的數(shù)據(jù)诊胞，都會(huì)從redo log中抹除暖夭，數(shù)據(jù)庫(kù)重啟后，直接將redo log的數(shù)據(jù)恢復(fù)到內(nèi)存撵孤。

3.3 未提交的事務(wù)日志也在Redo log中

因?yàn)椴煌聞?wù)的日志在Redo log是交叉存在的迈着，所以沒(méi)有辦法把未提交的事務(wù)與已提交的事務(wù)分開(kāi)。ARIES的做法是：不管事務(wù)有沒(méi)有提交邪码，它的日志都會(huì)被記錄在Redo log上并刷到磁盤中裕菠。當(dāng)崩潰的時(shí)候，會(huì)把Redo log全部回放一遍闭专，然后再把未提交的事務(wù)給找出來(lái)奴潘，做回滾處理旧烧。

4. 寫磁盤flush操作

InnoDB執(zhí)行update更新操作是采用的“先寫日志，在寫磁盤”的策略画髓。更新后的行數(shù)據(jù)本身先緩存在內(nèi)存中掘剪，直將縮略的關(guān)鍵信息寫入到redo log磁盤。但緩存在內(nèi)存中的數(shù)據(jù)最終總是要寫入到磁盤奈虾，這個(gè)操作叫做flush夺谁。

當(dāng)內(nèi)存數(shù)據(jù)頁(yè)和磁盤數(shù)據(jù)頁(yè)不一致的時(shí)候，稱這個(gè)內(nèi)存頁(yè)為“臟頁(yè)”肉微。內(nèi)存數(shù)據(jù)寫入到磁盤后匾鸥，內(nèi)存和磁盤上的數(shù)據(jù)頁(yè)的內(nèi)容就一致了，稱為“干凈頁(yè)”碉纳。flush操作也就是“刷臟頁(yè)”扫腺。

4.1 觸發(fā)數(shù)據(jù)庫(kù)執(zhí)行flush操作的四種情況：

4.1.1 當(dāng)InnoDB的redo log寫滿時(shí)

此時(shí)系統(tǒng)會(huì)停止所有的更新操作，將環(huán)形的redo log中的“讀指針”向前推村象，對(duì)應(yīng)的所有臟頁(yè)此時(shí)都會(huì)flush到磁盤上笆环。

4.1.2 當(dāng)系統(tǒng)的內(nèi)存不足時(shí)

當(dāng)需要新的內(nèi)存頁(yè)，但是內(nèi)存不夠用時(shí)厚者，就需要淘汰一些內(nèi)存頁(yè)（一般是空出最長(zhǎng)時(shí)間沒(méi)有被訪問(wèn)的內(nèi)存頁(yè)）躁劣，此時(shí)如果淘汰的是臟頁(yè)，就需要先將臟頁(yè)寫到磁盤库菲。

4.1.3 當(dāng)mysql認(rèn)為系統(tǒng)“空閑”時(shí)

mysql會(huì)在運(yùn)行期間“見(jiàn)縫插針”的找機(jī)會(huì)刷一點(diǎn)臟頁(yè)账忘，以避免當(dāng)讀寫業(yè)務(wù)繁忙時(shí)過(guò)快的占滿系統(tǒng)內(nèi)存或redo log空間。

4.1.4 當(dāng)mysql正常關(guān)閉時(shí)

此時(shí)mysql會(huì)把內(nèi)存中所有臟頁(yè)都flush到磁盤上熙宇，這樣mysql下次啟動(dòng)的時(shí)候就直接從磁盤上讀取數(shù)據(jù)鳖擒，啟動(dòng)速度更快（相比即從磁盤讀取數(shù)據(jù)，又從磁盤讀取redo log日志）烫止。

參考文章

MySQL日志系統(tǒng)：一條SQL“更新語(yǔ)句”是如何執(zhí)行的（redo log蒋荚、binlog）

淺析MySQL事務(wù)中的redo與undo

理解Mysql中的Buffer pool

邏輯日志與物理日志

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市馆蠕，隨后出現(xiàn)的幾起案子期升，更是在濱河造成了極大的恐慌，老刑警劉巖互躬，帶你破解...
    沈念sama閱讀 216,372評(píng)論 6贊 498
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件播赁，死亡現(xiàn)場(chǎng)離奇詭異，居然都是意外死亡吼渡，警方通過(guò)查閱死者的電腦和手機(jī)容为，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,368評(píng)論 3贊 392
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)，“玉大人坎背，你說(shuō)我怎么就攤上這事竭缝。” “怎么了沼瘫？”我有些...
    開(kāi)封第一講書(shū)人閱讀 162,415評(píng)論 0贊 353
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵抬纸，是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我耿戚，道長(zhǎng)湿故，這世上最難降的妖魔是什么？ 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 58,157評(píng)論 1贊 292
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任膜蛔，我火速辦了婚禮坛猪，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘皂股。我一直安慰自己墅茉，他們只是感情好，可當(dāng)我...
    茶點(diǎn)故事閱讀 67,171評(píng)論 6贊 388
  • 惡毒庶女頂嫁案：這布局不是一般人想出來(lái)的
    文/花漫 我一把揭開(kāi)白布呜呐。 她就那樣靜靜地躺著就斤，像睡著了一般。 火紅的嫁衣襯著肌膚如雪蘑辑。 梳的紋絲不亂的頭發(fā)上洋机，一...
    開(kāi)封第一講書(shū)人閱讀 51,125評(píng)論 1贊 297
  • 城市分裂傳說(shuō)
    那天，我揣著相機(jī)與錄音洋魂，去河邊找鬼绷旗。 笑死，一個(gè)胖子當(dāng)著我的面吹牛副砍，可吹牛的內(nèi)容都是我干的衔肢。 我是一名探鬼主播，決...
    沈念sama閱讀 40,028評(píng)論 3贊 417
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開(kāi)眼豁翎，長(zhǎng)吁一口氣：“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼角骤！你這毒婦竟也來(lái)了？” 一聲冷哼從身側(cè)響起谨垃，我...
    開(kāi)封第一講書(shū)人閱讀 38,887評(píng)論 0贊 274
  • 萬(wàn)榮殺人案實(shí)錄
    序言：老撾萬(wàn)榮一對(duì)情侶失蹤启搂，失蹤者是張志新（化名）和其女友劉穎，沒(méi)想到半個(gè)月后刘陶，有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 45,310評(píng)論 1贊 310
  • ?護(hù)林員之死
    正文 獨(dú)居荒郊野嶺守林人離奇死亡牢撼，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,533評(píng)論 2贊 332
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年匙隔，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片熏版。...
    茶點(diǎn)故事閱讀 39,690評(píng)論 1贊 348
  • 活死人
    序言：一個(gè)原本活蹦亂跳的男人離奇死亡纷责，死狀恐怖捍掺，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情再膳，我是刑警寧澤挺勿，帶...
    沈念sama閱讀 35,411評(píng)論 5贊 343
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站喂柒，受9級(jí)特大地震影響不瓶，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜灾杰，卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,004評(píng)論 3贊 325
  • 男人毒藥：我在死后第九天來(lái)索命
    文/蒙蒙 一蚊丐、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧艳吠，春花似錦麦备、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 31,659評(píng)論 0贊 22
  • 一樁弒父案凛篙，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至栏渺，卻和暖如春鞋诗，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背迈嘹。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 32,812評(píng)論 1贊 268
  • 情欲美人皮
    我被黑心中介騙來(lái)泰國(guó)打工削彬， 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留耕餐，地道東北人勒魔。 一個(gè)月前我還...
    沈念sama閱讀 47,693評(píng)論 2贊 368
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長(zhǎng)得像狮腿，于是被迫代替她去往敵國(guó)和親神僵。 傳聞我的和親對(duì)象是個(gè)殘疾皇子雁刷，可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,577評(píng)論 2贊 353

推薦閱讀更多精彩內(nèi)容