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

從 Buffer Pool（內(nèi)存中） 中查看是否有這條數(shù)據(jù)，沒(méi)有就從磁盤中加載到緩沖池，然后對(duì)這行記錄加獨(dú)占鎖；

把更新行記錄的舊值寫入 undo log（以便回滾）；

更新 Buffer Pool 中的數(shù)據(jù)（成臟數(shù)據(jù)）；

執(zhí)行器把對(duì)數(shù)據(jù)的修改情況寫入 redo log 中（內(nèi)存中） ；

準(zhǔn)備提交事務(wù)時(shí)（prepare 階段），按策略把 redo log 刷到 redo log 文件（磁盤中）；

執(zhí)行器生成這次更新的 binlog，再按策略刷到 binlog 文件（磁盤中）；

執(zhí)行器調(diào)用引擎的提交事務(wù)接口，完成最終的事務(wù)提交。（此時(shí)會(huì)把本次更新對(duì)應(yīng)的 binlog 文件名稱和這次更新的 binlog 文件里的位置，寫入到 redo log 文件中，同時(shí)在 redo log 文件里寫入一個(gè) commit 標(biāo)記）

如果觸發(fā)刷新臟頁(yè)的操作，則將內(nèi)存更新后的臟數(shù)據(jù)刷回磁盤。

圖2 update語(yǔ)句執(zhí)行流程框架圖

首先客戶端通過(guò) tcp/ip 發(fā)送一條 sql 語(yǔ)句到 server 層的 SQL interface；

SQL interface 接到該請(qǐng)求后，先對(duì)該條語(yǔ)句進(jìn)行解析，驗(yàn)證權(quán)限是否匹配；

驗(yàn)證通過(guò)以后，分析器會(huì)對(duì)該語(yǔ)句分析，是否語(yǔ)法有錯(cuò)誤等；

接下來(lái)是優(yōu)化器器生成相應(yīng)的執(zhí)行計(jì)劃，選擇最優(yōu)的執(zhí)行計(jì)劃；

之后會(huì)是執(zhí)行器根據(jù)執(zhí)行計(jì)劃執(zhí)行這條語(yǔ)句。

• 在這一步會(huì)去 open table，如果該 table 上有 MDL 則等待。
• 如果沒(méi)有，則加在該表上加短暫的 MDL(S)。
• (如果 opend_table 太大，表明 open_table_cache 太小。需要不停的去打開 frm 文件)；

進(jìn)入到引擎層，首先會(huì)去 innodb_buffer_pool 里的 data dictionary (元數(shù)據(jù)信息) 得到表信息；

通過(guò)元數(shù)據(jù)信息，去 lock info 里查出是否會(huì)有相關(guān)的鎖信息，并把這條 update 語(yǔ)句需要的鎖信息寫入到 lock info 里(鎖這里還有待補(bǔ)充)；

然后涉及到的老數(shù)據(jù)通過(guò)快照的方式存儲(chǔ)到 innodb_buffer_pool 里的 undo page 里，并且記錄 undo log 修改的 redo（如果 data page 里有就直接載入到 undo page 里，如果沒(méi)有，則需要去磁盤里取出相應(yīng) page 的數(shù)據(jù)，載入到 undo page 里）；

在 innodb_buffer_pool 的 data page 做 update 操作。并把操作的物理數(shù)據(jù)頁(yè)修改記錄到 redo log buffer 里，由于 update 這個(gè)事務(wù)會(huì)涉及到多個(gè)頁(yè)面的修改，所以 redo log buffer 里會(huì)記錄多條頁(yè)面的修改信息。因?yàn)?group commit 的原因，這次事務(wù)所產(chǎn)生的 redo log buffer 可能會(huì)跟隨其它事務(wù)一同 flush 并且 sync 到磁盤上；

同時(shí)修改的信息，會(huì)按照 event 的格式，記錄到 binlog_cache 中。(這里注意 binlog_cache_size 是 transaction 級(jí)別的，不是 session 級(jí)別的參數(shù)，一旦 commit 之后，dump 線程會(huì)從 binlog_cache 里把 event 主動(dòng)發(fā)送給 slave 的 I/O 線程)；

之后把這條 sql，需要在二級(jí)索引上做的修改，寫入到 change buffer page，等到下次有其他 sql 需要讀取該二級(jí)索引時(shí)，再去與二級(jí)索引做 merge 。

(隨機(jī)I/O變?yōu)轫樞騃/O，但是由于現(xiàn)在的磁盤都是SSD，所以對(duì)于尋址來(lái)說(shuō)，隨機(jī)I/O和順序I/O差距不大)；

此時(shí) update 語(yǔ)句已經(jīng)完成，需要 commit 或者 rollback。這里討論 commit 的情況；

• commit 操作，由于存儲(chǔ)引擎層與 server 層之間采用的是內(nèi)部 XA (保證兩個(gè)事務(wù)的一致性，這里主要保證 redo log 和 binlog 的原子性)，所以提交分為 prepare 階段與 commit 階段；
• prepare 階段，將事務(wù)的 xid 寫入，將 binlog_cache 里的進(jìn)行 flush 以及 sync 操作(大事務(wù)的話這步非常耗時(shí))；
• commit 階段，由于之前該事務(wù)產(chǎn)生的 redo log 已經(jīng) sync 到磁盤了。所以這步只是在 redo log 里標(biāo)記 commit；

當(dāng) binlog 和 redo log 都已經(jīng)落盤以后，如果觸發(fā)了刷新臟頁(yè)的操作，先把該臟頁(yè)復(fù)制到 doublewrite buffer 里，把 doublewrite buffer 里的刷新到共享表空間，然后才是通過(guò) page cleaner 線程把臟頁(yè)寫入到磁盤中。

其實(shí)在實(shí)現(xiàn)上5是調(diào)用了6的過(guò)程了的，所以是一回事。MySQL server 層和InnoDB層都保存了表結(jié)構(gòu)，所以有書上描述時(shí)會(huì)拆開說(shuō)。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論