1.undo log和redo log了解過(guò)嗎？它們的作?分別是什么,？

2.redo log是如何保證事務(wù)不丟失的,？

3.mysql的事務(wù)是先提交還是先刷盤(pán)？

4.更新操作為什么不直接更新磁盤(pán)反而設(shè)計(jì)這樣?個(gè)復(fù)雜的InnoDB存儲(chǔ)引擎來(lái)完成,？

下面我們開(kāi)始逐步探索Mysql架構(gòu)的運(yùn)行流程,。

前臺(tái)?戶各種操作觸發(fā)后臺(tái)sql執(zhí)?，通過(guò)web項(xiàng)?中?帶的數(shù)據(jù)庫(kù)連接池：如dbcp,、c3p0,、druid等，與數(shù)據(jù)庫(kù)服務(wù)器的數(shù)據(jù)庫(kù)連接池建??絡(luò)連接,；

數(shù)據(jù)庫(kù)連接池中的線程監(jiān)聽(tīng)到請(qǐng)求后,，將接收到的sql語(yǔ)句通過(guò)SQL接?響應(yīng)給查詢解析器，

查詢解析器將sql按照sql的語(yǔ)法解析出查詢哪個(gè)表的哪些字段,，查詢條件是啥,；

再通過(guò)查詢優(yōu)化器處理，選擇該sql最優(yōu)的?套執(zhí)?計(jì)劃,，然后執(zhí)?器負(fù)責(zé)調(diào)?存儲(chǔ)引擎的?系列接?,，執(zhí)?該計(jì)劃?完成整個(gè)sql語(yǔ)句的執(zhí)行，如下圖所示：

具體執(zhí)?這些執(zhí)?計(jì)劃得要存儲(chǔ)引擎來(lái)完成,，比如?次更新users表中id=10的這條數(shù)據(jù),，緩沖池中?開(kāi)始肯定沒(méi)有該條數(shù)據(jù)的，

得要先從磁盤(pán)中將被更新數(shù)據(jù)的原始數(shù)據(jù)加載到緩沖池中（這?涉及到的innodb buffer暫時(shí)不講）,。

同時(shí)為了保證并發(fā)更新數(shù)據(jù)安全問(wèn)題,，會(huì)對(duì)這條數(shù)據(jù)先加鎖，防?其他事務(wù)進(jìn)?更新,。

接著將更新前的值先備份寫(xiě)?到undo log中（便于事務(wù)回滾時(shí)取舊數(shù)據(jù)）,，?如update語(yǔ)句即存儲(chǔ)被更新字段之前的值。

最后更新緩存?中的數(shù)據(jù)為最新的數(shù)據(jù),，?此就完成了在緩沖池中的執(zhí)?流程,，如下圖所示： 

緩沖池中更新完數(shù)據(jù)后，需要將本次的更新信息順序?qū)懙絉edo Log?志以及Binlog?志中（此時(shí)信息還在內(nèi)存中）,，

Redo Log刷盤(pán)策略由innodb_flush_log_at_trx_commit屬性值來(lái)定,，

0：不會(huì)寫(xiě)到磁盤(pán)，宕機(jī)會(huì)導(dǎo)致已提交事務(wù)數(shù)據(jù)丟失

1：數(shù)據(jù)過(guò)來(lái)即寫(xiě)磁盤(pán)，做到教據(jù)零丟失但是效率會(huì)很低

2：寫(xiě)到os cache,，每秒刷新一次到磁盤(pán),，宕機(jī)最多丟失1s的數(shù)據(jù)，速度夠快

Binlog刷盤(pán)策略由sync_binlog屬性來(lái)定,，

1：強(qiáng)制刷盤(pán),；0：寫(xiě)入os cache。

?般我們?yōu)榱吮ＷC數(shù)據(jù)不丟失會(huì)配置雙1策略,，

Redo Log落盤(pán)后,，寫(xiě)B(tài)inlog落盤(pán)，再將Binlog的?件名,、?件所在路徑信息以及commit標(biāo)記給同步順序?qū)懙絉edolog中（其中commit標(biāo)記是否更新到Redo Log中,，是判定事務(wù)是否成功提交的?個(gè)?較重要的標(biāo)準(zhǔn)），

Redo Log和BinLog分別在物理和邏輯層?為本次事務(wù),、提供數(shù)據(jù)上的?致性保障,，如下圖所示

前??些列操作執(zhí)?成功后，InnoDB存儲(chǔ)引擎后臺(tái)有?個(gè)IO線程,，會(huì)在數(shù)據(jù)庫(kù)壓?的低峰期間時(shí)如凌晨時(shí)分,，

將緩沖池中被事務(wù)更新、但還沒(méi)來(lái)得及寫(xiě)到磁盤(pán)中的數(shù)據(jù)（臟數(shù)據(jù),，因?yàn)榇疟P(pán)數(shù)據(jù)和內(nèi)存數(shù)據(jù)已經(jīng)不?致了）給刷到磁盤(pán)中,，完成事務(wù)的持久化。

1.undo log和redo log了解過(guò)嗎,？它們的作?分別是什么,？

undo log和redo log是mysql中InnoDB存儲(chǔ)引擎的基本組成：

（1）undo log保存了事務(wù)執(zhí)?前數(shù)據(jù)的值，以便于事務(wù)回滾時(shí)能回到事務(wù)執(zhí)?前的數(shù)據(jù)版本,，多次更

新會(huì)有undo log的版本鏈,；

（2）redo log在物理層?上記錄了事務(wù)操作的?系列信息，保證就算遇到mysql宕機(jī)等因素還沒(méi)來(lái)得

及將數(shù)據(jù)刷到磁盤(pán)?,，通過(guò)redo log也能恢復(fù)事務(wù)提交的數(shù)據(jù),。

2.redo log怎樣保證事務(wù)不丟失的？

當(dāng)?個(gè)事務(wù)提交成功后,，雖然緩沖池中的數(shù)據(jù)不?定來(lái)得及?上落地到磁盤(pán)中,，但是redo log記錄的

事務(wù)信息持久化到磁盤(pán)中了、且含有commit標(biāo)記,，此時(shí)如果mysql宕機(jī)導(dǎo)致緩沖池中的,、已經(jīng)被事務(wù)更新

過(guò)的內(nèi)存數(shù)據(jù)丟失了,，此時(shí)在mysql重啟時(shí),，將磁盤(pán)中的redo log中將事務(wù)變更信息給加載到緩沖池中，

保證事務(wù)信息不會(huì)丟失?；蛘遰edo log刷盤(pán)了,，binlog寫(xiě)成功了，在重啟時(shí)會(huì)?動(dòng)給上commit標(biāo)記,，在重

放數(shù)據(jù),。

3.事務(wù)是先提交還是先刷盤(pán)？

事務(wù)先提交后刷盤(pán),；

1.Redo log刷盤(pán)成功->2.Binlog刷盤(pán)->3.BinLog名稱和?件路徑信息,、commit標(biāo)志寫(xiě)到Redo log

中，事務(wù)兩階段提交的?式來(lái)保證,。

4.更新操作為什么不直接更新磁盤(pán)反?設(shè)計(jì)這樣?個(gè)復(fù)雜的InnoDB存儲(chǔ)引擎來(lái)完成,？

直接更新磁盤(pán)是隨機(jī)IO寫(xiě)，存在磁盤(pán)地址尋址操作,，性能?常低,，承載不了?并發(fā)場(chǎng)景；

?轉(zhuǎn)換為InnoDB中,，內(nèi)存?速讀寫(xiě),、redo log和undo log順序?qū)懘疟P(pán)性能相對(duì)于隨機(jī)IO寫(xiě)性能會(huì)?

的多，?這種性能上的提??以抵消這種架構(gòu)上帶來(lái)的復(fù)雜,，可在?定QPS內(nèi)承載?并發(fā)場(chǎng)景,。