Mysql 百問系列： update 語句到底作了些什麼？

問題：

一條簡單的update 的語句到底牽扯了多少的東西？你能徹底說明白嗎？

來看看具體流程：

## student 只有id, 和name  兩個字段，且只有id 一個主鍵，無其餘索引。

update student set name = 'gxw' where id = 2
複製代碼

1. 開啓事務，將原內容寫入undo log。
2. 去Buffer Pool 中 查找id =2 所對應的數據。
3. 若是在Buffer Pool中查找到了對應的數據，那麼直接在Buffer Pool 中直接修改對應數據。若是沒有找到，那麼先從磁盤中找到對應數據，而後加載到Buffer Pool 中進行修改。
4. 將更新的內容寫入redo log。
5. 若是開啓了binlog ，還會寫入binlog日誌。
6. 事務提交進入prepare 階段，將redo log 刷入磁盤
7. 事務提交進入commit 階段， 將binlog 輸入磁盤

分析下每一個階段幹了什麼，爲何要這麼作？

步驟1，mysql 默認配置每一個單獨的更新語句都會開啓一個事務。因此上面這個語句第一步確定是開啓一個事務。
開啓事務的同時，把原紀錄寫入undo log。 

爲何須要寫undo log?

• undo log 能夠支持rollback(回滾）操做。咱們知道若是人工開啓一個事務，咱們是能夠手動調用RollBack 命令進行回滾事務的，固然若是容許事務過程當中，服務器出現問題，mysql服務重啓後也是能夠進行自動回滾。而爲了實現這個回滾功能，就須要用到undo log。
• Mysql 的MVCC (``多版本併發控制）也是經過undo log 來實現的。

步驟2和步驟3，在Buffer Pool 中查找數據並修改。 Buffer Pool 在這就很少解釋了，我已經有專門的文章介紹，有興趣的同窗能夠翻看個人其餘文章。一句話歸納就是問題避免過多的磁盤操做，增長的緩存。

步驟4， 將新內容寫入redo log。

爲何須要redo log？

• redo log 是爲何誕生呢？ 咱們說了Buffer Pool 是在內存中的，若是Mysql服務忽然崩潰，或者服務器停電，那麼放在Buffer Pool 中的數據就都會丟失。因爲咱們修改的時候只修改了Buffer Pool 中的內容，有部份內容修改了但還沒往磁盤刷（所謂的髒頁），爲了不髒頁數據丟失，因此設計了redo log。詳細瞭解redo log 機能也可查看我以往的文章。

步驟5，寫binlog 。 相信不少人對binlog 比較熟悉，它能夠開啓，也能夠關閉。它不影響事務的功能，但它提供了額外的功能，好比回溯的能力，好比你但願把數據庫放回到2020-01-01 00:00:00 的時候，這時候就須要藉助binlog了。 固然binlog 還有一個功能是實現主備同步。 Mysql 的 一主多從，雙主多從等都是經過binlog 實現的。

步驟6，步驟7， 事務兩階段提交。（限制於篇幅詳細不展開了，之後開專門的文章介紹）。 簡單的說它是保證redo log 和 binlog 的一致性。當咱們輸入COMMIT 命令時，實際上是通過了prepare 和commit 兩個階段的。

到這就介紹完一個最簡單的更新語句的流程了。
若是再複雜點的狀況呢？

當存在二級非惟一索引的時候

什麼意思呢？ 好比產品提了個需求說，我須要按照姓名來查找數據。爲了提升搜索速度，咱們可能就會爲name 字段加上索引，因爲姓名容許重複，那這個索引就不會被設置成惟一索引。假設索引名爲index_name
咱們知道index_name 的數據也會被存放在各個數據頁中。
那麼上面的修改語句，將id = 2 的name 修改成'gxw' 。那麼除了修改數據頁中的數據，index_name 的索引頁中的數據也須要相應修改。
若是是你，你會怎麼作？  從Buffer Pool 中的查找對應的index_name 中的數據，若是存在則修改，若是不存在，則到磁盤中查找數據加載到Buffer Pool中進行修改。能夠看到這裏須要一次磁盤操做，若是有多個二級非惟一索引那可能須要屢次磁盤操做，影響效率。Mysql 的工程師爲了優化，就又加入了change log。
也就是說若是一個表中有二級非惟一索引，那麼執行update 操做可能會用到change log

總結：

一個簡單的更新語句，會涉及到的東西： undo log , Buffer Pool, redo log ,change log , binlog 。如今你能夠不瞭解他們具體是如何工做的，但但願經過這篇文章你已經知道了他們究竟是爲了什麼目的而存在的。