被面試官問“Mysql”，update 語句到底做了些什麼？
問題：
一條簡單的update 的語句到底牽扯了多少的東西？你能完全說明白嗎？
看看具體流程：
前提: student 只有id, 和name 兩個字段，且只有id 一個主鍵，無其他索引。
update student set name = 'gxw' where id = 2
- 開啓事務，將原內容寫入undo log。
- 去Buffer Pool 中 查找id =2 所對應的數據。
- 如果在Buffer Pool中查找到了對應的數據，那麼直接在Buffer Pool 中直接修改對應數據。如果沒有找到，那麼先從磁盤中找到對應數據，然後加載到Buffer Pool 中進行修改。
- 將更新的內容寫入redo log。
- 如果開啓了binlog ，還會寫入binlog日誌。
- 事務提交進入prepare 階段，將redo log 刷入磁盤
- 事務提交進入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 。現在你可以不瞭解他們具體是如何工作的，但希望通過這篇文章你已經知道了他們到底是爲了什麼目的而存在的。