一條SQL語句執行步驟
來源于MySQL實戰
mysql> select * from T where ID=10；
查詢語句執行分析
MySQL分為Server層和存儲引擎層
-
連接器：
負責跟客戶端建立鏈接、獲取權限、維持和管理連接- 如果用戶名或密碼不對，你就會收到一個"Access denied for user"的錯誤，然后客戶端程序結束執行。
- 如果用戶名密碼認證通過，連接器會到權限表里面查出你擁有的權限。之后，這個連接里面的權限判斷邏輯，都將依賴于此時讀到的權限。
查詢緩存：
MySQL拿到一個查詢請求后，會先到查詢緩存內看看，之前是否執行過這條語句。之前的語句及其結果以key-value對的形式緩存在內存中。
大多數情況下不建議使用查詢緩存，因為查詢緩存失效非常頻繁。只要表中有數據更新，則這個表上的所有查詢緩存都會被清空。
靜態表適合查詢緩存。分析器：
如果沒有命中查詢緩存，則開始真正執行語句。
分析器先進行詞法分析，主要識別sql語句中各個字符串代表的含義。然后進行語法分析，根據語法規則判斷輸入語句是否滿足MySql語法。優化器：
在表里有多個索引時，決定用哪個索引。或者多表關聯(join)時，決定各個表的連接順序。執行器：
MySql通過分析器知道了要做什么，通過優化器知道了該怎么做，下一步就進入執行器開始執行語句。
1.先判斷對表T有沒有執行權限；
2.如果有權限，則根據表中引擎定義，使用引擎提供的相關接口。
更新語句執行分析
- 首先可以確認的是查詢語句的那一套流程，更新語句也是同樣走一遍。與查詢流程不一樣的是，更新流程還涉及兩個重要的日志模塊。也就是下面要分析的兩個主角：redo log(重做日志)、binlog(歸檔日志)
- 為什么會有兩份日志呢？因為最開始并沒有InnoDB引擎，數據庫自帶的引擎是MyISAM，這個引擎并沒有crash-safe能力，所有后續的InnoDB使用了另外一套日志
- 兩種日志存在三點不同。
1.redo log屬于引擎日志，binlog屬于服務層日志；
2.redo log是物理日志，記錄的是“在某個數據頁上做了什么修改”;binlog是邏輯日志，記錄的是這個語句的原始邏輯,比如"給ID=2這一行的c字段加1";
3.redo 是循環寫，binlog可以追加寫；
- redo log(引擎層日志)
- 如果每次更新操作，數據庫都需要查詢磁盤，然后找到對應的記錄，再更新記錄，整個過程IO成本、查找成本很高。基于以上情況，MySql先順序落盤，然后等空閑時在更新數據。MySql的WAL(Write-Ahead Logging)技術，關鍵點就是先寫日志(循序寫盤)，再寫磁盤。
- 數據庫中InnoDB的redo log是固定大小的，在循環使用時，需要保證被擦掉的數據已經更新到磁盤中。有了redo log，InnoDB就可以保證數據庫發生異常重啟，之前提交的記錄都不會丟失，這就是crash-safe
- binlog(Server層日志)
mysql> update T set c=c+1 where ID=2;
- 執行器先找引擎取ID=2這一行。引擎判斷這一行所在數據頁是否在內存中，是則直接返回，否則先從磁盤讀入內存，然后再返回；
- 執行器拿到行數據后，更新行數據，并調用引擎接口寫入數據；
- 引擎更新內存中數據頁，并將更新操作記錄到redo log里面，此時redo log處于prepare狀態。告之執行器執行完成了，可以隨時提交事務。
- 執行器生成該操作的binlog，并把binlog寫入磁盤；
5.執行器調用引擎的提交事務接口,引擎把剛剛寫入的redo log改成提交(commit)狀態，更新完成。
以下是相關執行流程圖：
??大家可能注意到，最后三步看上去有點“繞”,將redo log的寫入拆分成兩個步驟：prepare和commit，這就是“兩階段提交”
怎樣讓數據庫恢復到半月內任意一秒的狀態？
仍然用前面的 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，與原庫的值不同。
MySQL 使用兩階段提交主要解決 binlog 和 redo log 的數據一致性的問題。
崩潰恢復規則
redo log 和 binlog 有一個共同的數據字段，叫 XID。崩潰恢復的時候，會按順序掃描 redo log：
如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
如果碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應的事務。
binlog無記錄，回滾事務
binlog有記錄，提交事務。
