在面試中面試中如果被面試官問(wèn)到在MySQL中一條更新語(yǔ)句是怎么執(zhí)行的？，下面讓我們來(lái)探究一下！

流程圖

這是在網(wǎng)上找到的一張流程圖，寫的比較好，大家可以先看圖，然后看詳細(xì)閱讀下面的各個(gè)步驟。

執(zhí)行流程：

1.連接驗(yàn)證及解析

客戶端與MySQL Server建立連接，發(fā)送語(yǔ)句給MySQL Server，接收到后會(huì)針對(duì)這條語(yǔ)句創(chuàng)建一個(gè)解析樹，然后進(jìn)行優(yōu)化，(解析器知道語(yǔ)句是要執(zhí)行什么，會(huì)評(píng)估使用各種索引的代價(jià)，然后去使用索引，以及調(diào)節(jié)表的連接順序)然后調(diào)用innodb引擎的接口來(lái)執(zhí)行語(yǔ)句。

2.寫undo log

innodb 引擎首先開(kāi)啟事務(wù)，對(duì)舊數(shù)據(jù)生成一個(gè)UPDATE的語(yǔ)句(如果是INSERT會(huì)生成UPDATE語(yǔ)句)，用于提交失敗后回滾，寫入undo log，得到回滾指針，并且更新這個(gè)數(shù)據(jù)行的回滾指針和版本號(hào)(會(huì)設(shè)置為更新的事務(wù)id)。

3.從索引中查找數(shù)據(jù)

根據(jù)查詢條件去B+樹中找到這一行數(shù)據(jù)(如果是唯一性索引，查到第一個(gè)數(shù)據(jù)就可以了(因?yàn)橛形ㄒ恍约s束)，如果是普通索引，會(huì)把所有數(shù)據(jù)查找出來(lái)。)

4.更新數(shù)據(jù)

首先判斷數(shù)據(jù)頁(yè)是否在內(nèi)存中？

4.1 如果數(shù)據(jù)頁(yè)在內(nèi)存中

先判斷更新的索引是普通索引還是唯一性索引？

4.1.1 普通索引

如果更新的索引是普通索引，直接更新內(nèi)存中的數(shù)據(jù)頁(yè)

4.1.2 唯一性索引

如果更新的索引是唯一性索引，判斷更新后是否會(huì)破壞數(shù)據(jù)的唯一性，不會(huì)的話就更新內(nèi)存中的數(shù)據(jù)頁(yè)。

4.2 如果數(shù)據(jù)頁(yè)不在內(nèi)存中

先判斷更新的索引是普通索引還是唯一性索引？

4.2.1 普通索引

如果是更新的索引是普通索引，將對(duì)數(shù)據(jù)頁(yè)的更新操作記錄到change buffer，change buffer會(huì)在空閑時(shí)異步更新到磁盤。

4.2.2 唯一性索引

如果是更新的索引是唯一性索引，因?yàn)樾枰ＷC更新后的唯一性，所以不能延遲更新，必須把數(shù)據(jù)頁(yè)從磁盤加載到內(nèi)存，然后判斷更新后是否會(huì)數(shù)據(jù)沖突，不會(huì)的話就更新數(shù)據(jù)頁(yè)。

5.寫undo log(prepare狀態(tài))

將對(duì)數(shù)據(jù)頁(yè)的更改寫入到redo log，將redo log設(shè)置為prepare狀態(tài)。

6.寫bin log(commit狀態(tài))，提交事務(wù)

通知MySQL server已經(jīng)更新操作寫入到redo log 了，隨時(shí)可以提交，將執(zhí)行的SQL寫入到bin log日志，將redo log改成commit狀態(tài)，事務(wù)提交成功。(一個(gè)事務(wù)是否執(zhí)行成功的判斷依據(jù)是是否在bin log中寫入成功。寫入成功后，即便MySQL Server崩潰，之后恢復(fù)時(shí)也會(huì)根據(jù)bin log， redo log進(jìn)行恢復(fù)。具體可以看看下面的崩潰恢復(fù)原則)

補(bǔ)充資料：

二段提交制是什么？

更新時(shí)，先改內(nèi)存中的數(shù)據(jù)頁(yè)，將更新操作寫入redo log日志，此時(shí)redo log進(jìn)入prepare狀態(tài)，然后通知MySQL Server執(zhí)行完了，隨時(shí)可以提交，MySQL Server將更新的SQL寫入bin log，然后調(diào)用innodb接口將redo log設(shè)置為提交狀態(tài)，更新完成。

如果只是寫了bin log就提交，那么忽然發(fā)生故障，主節(jié)點(diǎn)可以根據(jù)redo log恢復(fù)數(shù)據(jù)到最新，但是主從同步時(shí)會(huì)丟掉這部分更新的數(shù)據(jù)。

如果只是寫binlog，然后寫redo log，如果忽然發(fā)生故障，主節(jié)點(diǎn)根據(jù)redo log恢復(fù)數(shù)據(jù)時(shí)就會(huì)丟掉這部分?jǐn)?shù)據(jù)。

MySQL崩潰后，事務(wù)恢復(fù)時(shí)的判斷規(guī)則是怎么樣的？(以redolog是否commit或者binlog是否完整來(lái)確定)

如果 redo log 里面的事務(wù)是完整的，也就是已經(jīng)有了 commit 標(biāo)識(shí)，則直接提交；

如果 redo log 里面的事務(wù)只有完整的 prepare，則判斷對(duì)應(yīng)的事務(wù) binlog 是否存在并完整：a. 如果是，則提交事務(wù)；b. 否則，回滾事務(wù)。

undo log是什么？

undo log主要是保證事務(wù)的原子性，事務(wù)執(zhí)行失敗就回滾，用于在事務(wù)執(zhí)行失敗后，對(duì)數(shù)據(jù)回滾。undo log是邏輯日志，記錄的是SQL。(可以認(rèn)為當(dāng)delete一條記錄時(shí)，undo log中會(huì)記錄一條對(duì)應(yīng)的insert記錄，反之亦然，當(dāng)update一條記錄時(shí)，它記錄一條對(duì)應(yīng)相反的update記錄。)

在事務(wù)提交后，undo log日志不會(huì)立即刪除，會(huì)放到一個(gè)待刪除的鏈表中，有purge線程判斷是否有其他事務(wù)在使用上一個(gè)事務(wù)之前的版本信息，然后決定是否可以清理，簡(jiǎn)單的來(lái)說(shuō)就是前面的事務(wù)都提交成功了，這些undo才能刪除。

change buffer是什么(就是將更新數(shù)據(jù)頁(yè)的操作緩存下來(lái))

在更新數(shù)據(jù)時(shí)，如果數(shù)據(jù)行所在的數(shù)據(jù)頁(yè)在內(nèi)存中，直接更新內(nèi)存中的數(shù)據(jù)頁(yè)。

如果不在內(nèi)存中，為了減少磁盤IO的次數(shù)，innodb會(huì)將這些更新操作緩存在change buffer中，在下一次查詢時(shí)需要訪問(wèn)這個(gè)數(shù)據(jù)頁(yè)時(shí)，在執(zhí)行change buffer中的操作對(duì)數(shù)據(jù)頁(yè)進(jìn)行更新。

適合寫多讀少的場(chǎng)景，因?yàn)檫@樣即便立即寫了，也不太可能會(huì)被訪問(wèn)到，延遲更新可以減少磁盤I/O，只有普通索引會(huì)用到，因?yàn)槲ㄒ恍运饕?#xff0c;在更新時(shí)就需要判斷唯一性，所以沒(méi)有必要。

redo log 是什么？

redo log就是為了保證事務(wù)的持久性。因?yàn)閏hange buffer是存在內(nèi)存中的，萬(wàn)一機(jī)器重啟，change buffer中的更改沒(méi)有來(lái)得及更新到磁盤，就需要根據(jù)redo log來(lái)找回這些更新。

優(yōu)點(diǎn)是減少磁盤I/O次數(shù)，即便發(fā)生故障也可以根據(jù)redo log來(lái)將數(shù)據(jù)恢復(fù)到最新?tīng)顟B(tài)。

缺點(diǎn)是會(huì)造成內(nèi)存臟頁(yè)，后臺(tái)線程會(huì)自動(dòng)對(duì)臟頁(yè)刷盤，或者是淘汰數(shù)據(jù)頁(yè)時(shí)刷盤，此時(shí)收到的查詢請(qǐng)求需要等待，影響查詢。

總結(jié)

以上是生活随笔為你收集整理的mysql编写完怎么执行_面试官：一条MySQL更新语句是如何执行的？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。