一條SQL更新語句是如何執行的

mysql>

create
table t(id int
primary
key, c int);

mysql>

update t set c=c+
1where id=
2;

在乙個表上有更新的時候，跟這個表有關的查詢快取會失效，所以這條語句就會把表t上所有快取結果都清空。這也就是一般不建議使用查詢快取的原因。

接下來，分析器會通過詞法和語法解析知道這是一條更新語句。優化器決定要使用id這個索引。然後，執行器負責具體執行，找到這一行，然後更新。

與查詢流程不一樣的是，更新流程還涉及兩個重要的日誌模組：redo log（重做日誌）和 binlog（歸檔日誌）。酒店掌櫃有乙個粉板，專門用來記錄客人的賒賬記錄。如果賒賬的人不多，那麼可以把顧客名和賬目寫在板上。但如果賒賬的人多了，粉板總會有記不下的時候，這個時候掌櫃一定還有乙個專門記錄賒賬的賬本。

如果有人要賒賬或者還賬的話，掌櫃一般有兩種做法：

在生意紅火櫃檯很忙時，掌櫃一定會選擇後者，因為前者操作實在是太麻煩了。首先，得找到這個人的賒賬總額那條記錄。密密麻麻幾十頁，掌櫃要找到那個名字，可能還得帶上老花鏡慢慢找，找到之後再拿出算盤計算，最後再將結果寫回到賬本上。

這整個過程想想都麻煩。相比之下，還是先在粉板上記一下方便。如果掌櫃沒有粉板的幫助，每次記賬都得翻賬本，效率是不是低得讓人難以忍受？

同樣，在mysql裡也有這個問題，如果每一次的更新操作都需要寫進磁碟，然後磁碟也要找到對應的那條記錄，然後再更新，整個過程io成本、查詢成本都很高。為了解決這個問題，mysql的設計者就用了類似酒店掌櫃粉板的思路來提公升更新效率。

而粉板和賬本配合的整個過程，其實就是mysql裡經常說到的wal技術，wal的全稱是write-ahead logging(預寫式日誌)，它的關鍵點就是先寫日誌，再寫磁碟，也就是先寫粉板，等不忙的時候再寫賬本。

具體來說，當有一條記錄需要更新的時候，innodb引擎就會先把記錄寫到redo log（粉板）裡面，並更新記憶體，這個時候更新就算完成了。同時，innodb引擎會在適當的時候，將這個操作記錄更新到磁碟裡面，而這個更新往往是在系統比較空閒的時候做，這就像打烊以後掌櫃做的事。

如果今天賒賬的不多，掌櫃可以等打烊後再整理。但如果某天賒賬的特別多，粉板寫滿了，又怎麼辦呢？這個時候掌櫃只好放下手中的活兒，把粉板中的一部分賒賬記錄更新到賬本中，然後把這些記錄從粉板上擦掉，為記新賬騰出空間。

與此類似，innodb的redo log是固定大小的，比如可以配置為一組4個檔案，每個檔案的大小是1gb，那麼這塊「粉板」總共就可以記錄4gb的操作。從頭開始寫，寫到末尾就又回到開頭迴圈寫，如下面這個圖所示。

write pos是當前記錄的位置，一邊寫一邊後移，寫到第3號檔案末尾後就回到0號檔案開頭。checkpoint是當前要擦除的位置，也是往後推移並且迴圈的，擦除記錄前要把記錄更新到資料檔案。

write pos和checkpoint之間的是「粉板」上還空著的部分，可以用來記錄新的操作。如果write pos追上checkpoint，表示「粉板」滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把checkpoint推進一下。

有了redo log，innodb就可以保證即使資料庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。

要理解crash-safe這個概念，可以想想前面賒賬記錄的例子。只要賒賬記錄記在了粉板上或寫在了賬本上，之後即使掌櫃忘記了，比如突然停業幾天，恢復生意後依然可以通過賬本和粉板上的資料明確賒賬賬目。前面講過，mysql整體來看，其實就有兩塊：一塊是server層，它主要做的是mysql功能層面的事情；還有一塊是引擎層，負責儲存相關的具體事宜。上面聊到的粉板redo log是innodb引擎特有的日誌，而server層也有自己的日誌，稱為binlog（歸檔日誌）。

為什麼會有兩份日誌呢？

因為最開始mysql裡並沒有innodb引擎。mysql自帶的引擎是myisam，但是myisam沒有crash-safe的能力，binlog日誌只能用於歸檔。而innodb是另乙個公司以外掛程式形式引入mysql的，既然只依靠binlog是沒有crash-safe能力的，所以innodb使用另外一套日誌系統——也就是redo log來實現crash-safe能力。

這兩種日誌有以下三點不同。

redo log是innodb引擎特有的；binlog是mysql的server層實現的，所有引擎都可以使用。

redo log是物理日誌，記錄的是「在某個資料頁上做了什麼修改」；binlog是邏輯日誌，記錄的是這個語句的原始邏輯，比如「給id=2這一行的c欄位加1 」。

redo log是迴圈寫的，空間固定會用完；binlog是可以追加寫入的。「追加寫」是指binlog檔案寫到一定大小後會切換到下乙個，並不會覆蓋以前的日誌。

有了對這兩個日誌的概念性理解，我們再來看執行器和innodb引擎在執行這個簡單的update語句時的內部流程。

執行器先找引擎取id=2這一行。id是主鍵，引擎直接用樹搜尋找到這一行。如果id=2這一行所在的資料頁本來就在記憶體中，就直接返回給執行器；否則，需要先從磁碟讀入記憶體，然後再返回。

執行器拿到引擎給的行資料，把這個值加上1，比如原來是n，現在就是n+1，得到新的一行資料，再呼叫引擎介面寫入這行新資料。

引擎將這行新資料更新到記憶體中，同時將這個更新操作記錄到redo log裡面，此時redo log處於prepare狀態。然後告知執行器執行完成了，隨時可以提交事務。

執行器生成這個操作的binlog，並把binlog寫入磁碟。

執行器呼叫引擎的提交事務介面，引擎把剛剛寫入的redo log改成提交（commit）狀態，更新完成。

圖中淺色框表示是在innodb內部執行的，深色框表示是在執行器中執行的。

最後三步看上去有點「繞」，將redo log的寫入拆成了兩個步驟：prepare和commit，這就是"兩階段提交"。為什麼必須有「兩階段提交」呢？這是為了讓兩份日誌之間的邏輯一致。要說明這個問題，怎樣讓資料庫恢復到半個月內任意一秒的狀態？

binlog會記錄所有的邏輯操作，並且是採用「追加寫」的形式。如果dba承諾說半個月內可以恢復，那麼備份系統中一定會儲存最近半個月的所有binlog，同時系統會定期做整庫備份。這裡的「定期」取決於系統的重要性，可以是一天一備，也可以是一周一備。

當需要恢復到指定的某一秒時，比如某天下午兩點發現中午十二點有一次誤刪表，需要找回資料，那可以這麼做：

這樣臨時庫就跟誤刪之前的線上庫一樣了，然後可以把錶資料從臨時庫取出來，按需要恢復到線上庫去。

為什麼日誌需要「兩階段提交」?

由於redo log和binlog是兩個獨立的邏輯，如果不用兩階段提交，要麼就是先寫完redo log再寫binlog，或者採用反過來的順序。看看這兩種方式會有什麼問題。

仍然用前面的update語句來做例子。假設當前id=2的行，欄位c的值是0，再假設執行update語句過程中在寫完第乙個日誌後，第二個日誌還沒有寫完期間發生了crash，會出現什麼情況呢？

先寫redo log後寫binlog。假設在redo log寫完，binlog還沒有寫完的時候，mysql程序異常重啟。redo log寫完之後，系統即使崩潰，仍然能夠把資料恢復回來，所以恢復後這一行c的值是1。

但是由於binlog沒寫完就crash了，這時候binlog裡面就沒有記錄這個語句。因此，之後備份日誌的時候，存起來的binlog裡面就沒有這條語句。

然後發現，如果需要用這個binlog來恢復臨時庫的話，由於這個語句的binlog丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行c的值就是0，與原庫的值不同。

先寫binlog後寫redo log。如果在binlog寫完之後crash，由於redo log還沒寫，崩潰恢復以後這個事務無效，所以這一行c的值是0。但是binlog裡面已經記錄了「把c從0改成1」這個日誌。所以，在之後用binlog來恢復的時候就多了乙個事務出來，恢復出來的這一行c的值就是1，與原庫的值不同。

可以看到，如果不使用「兩階段提交」，那麼資料庫的狀態就有可能和用它的日誌恢復出來的庫的狀態不一致。

這個概率是不是很低，平時也沒有什麼動不動就需要恢復臨時庫的場景呀？

其實不是的，不只是誤操作後需要用這個過程來恢復資料。當需要擴容的時候，也就是需要再多搭建一些備庫來增加系統的讀能力的時候，現在常見的做法也是用全量備份加上應用binlog來實現的，這個「不一致」就會導致線上出現主從資料庫不一致的情況。

簡單說，redo log和binlog都可以用於表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致。

一條SQL更新語句的執行過程

目錄如果執行這條更新語句資料庫是如何執行的呢？update student set name 小明 where studentid 1根據之前說過的sql語句查詢的流程來說，只要表上有資料更新，有關查詢的索引就會失效，接下來分析器會根據每個單詞識別知道這是update語句，優化器根據這個id獲取需要...

日誌系統 一條SQL更新語句是如何執行的

一 重要的日誌模組 redo log wal技術 先寫日誌，再寫磁碟。具體是當有一條紀錄需要更新的時候，innodb引擎就會先把紀錄寫到redo log裡面，並更新記憶體，在引擎空閒的時候，將這個操作紀錄更新到磁碟裡面。1 redo log紀錄了這個資料頁做了什麼改動 2 redo log 是固定大...

一條SQL查詢語句是如何執行的

mysql可以分為server層和儲存引擎層兩部分 一條普通的查詢語是怎樣執行並返回結果了 聯結器查詢快取 大多數情況下建議不要使用查詢快取，查詢快取往往弊大於利。查詢快取的失效非常頻繁，只要有對乙個表的更新，這個表上所有的查詢快取都會被清空。分析器優化器 比如你執行下面這樣的語句，這個語句是執行兩...