MySql實戰45講【SQL查詢和更新執行流程】

01 | 基礎架構：一條SQL查詢語句是如何執行的？

SQL 語句在 MySQL的各個功能模塊中的執行過程

Server 層包括連接器、查詢緩存、分析器、優化器、執行器等，涵蓋 MySQL 的大多數核心服務功能，以及所有的內置函數（如日期、時間、數學和加密函數等），所有跨存儲引擎的功能都在這一層實現，比如存儲過程、觸發器、視圖等。

而存儲引擎層負責數據的存儲和提取。其架構模式是插件式的，支持 InnoDB、
MyISAM、Memory 等多個存儲引擎。現在最常用的存儲引擎是 InnoDB，它從 MySQL5.5.5 版本開始成為了默認存儲引擎。

其中的Command 列顯示為“Sleep”的這一行，就錶示現在系統裏面有一個空閑連接

客戶端如果太長時間沒動靜，連接器就會自動將它斷開。這個時間是由參數 wait_timeout 控制的，默認值是 8 小時

相關命令：

-- 是客戶端 非交互式的連接時間,單比特秒
SHOW VARIABLES LIKE 'wait_timeout%';
-- 是客戶端 交互式的連接時間,單比特秒
SHOW VARIABLES LIKE 'interactive_timeout%';

執行器流程


mysql慢日志

-- 查看是否開啟慢查詢日志功能
SHOW VARIABLES LIKE 'slow_query%';

# 開啟 MySQL 慢查詢日志功能
SET GLOBAL slow_query_log=ON;
# 設置慢sql的時間,執行時間超過 1 秒的 SQL 語句將被記錄到日志中
SET GLOBAL long_query_time=1;

02 | 日志系統：一條SQL更新語句是如何執行的？

在一個錶上有更新的時候，跟這個錶有關的查詢緩存會失效，所以這條語句就會把錶 T 上所有緩存結果都清空。這也就是我們一般不建議使用查詢緩存的原因

與查詢流程不一樣的是，更新流程還涉及兩個重要的日志模塊:redo log（重做日志）和 binlog（歸檔日志）

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.

MySQL 整體來看，其實就有兩塊：一塊是 Server 層，它主要做的是MySQL 功能層面的事情；還有一塊是引擎層，負責存儲相關的具體事宜.

redo log 是 InnoDB 引擎特有的日志，而 Server 層也有自己的日志，稱為binlog（歸檔日志）

這兩種日志有以下三點不同

1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎
   都可以使用。
2. redo log 是物理日志，記錄的是“在某個數據頁上做了什麼修改”；binlog 是邏輯日
   志，記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 字段加 1 ”。
3. redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的。“追加寫”是指
   binlog 文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日志

sql更新流程

1. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹搜索找到這一行。如果
   ID=2 這一行所在的數據頁本來就在內存中，就直接返回給執行器；否則，需要先從磁
   盤讀入內存，然後再返回。
2. 執行器拿到引擎給的行數據，把這個值加上 1，比如原來是 N，現在就是 N+1，得到
   新的一行數據，再調用引擎接口寫入這行新數據。
3. 引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log 裏面，此時
   redo log 處於 prepare 狀態。然後告知執行器執行完成了，隨時可以提交事務。
4. 執行器生成這個操作的 binlog，並把 binlog 寫入磁盤。
5. 執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀
   態，更新完成。

update 語句的執行流程圖，圖中淺色框錶示是在 InnoDB 內部執行的，深色框錶示是在執行器中執行的

redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是"兩階段提交"

binlog 會記錄所有的邏輯操作，並且是采用“追加寫”的形式。如果你的 DBA 承諾說半個月內可以恢複，那麼備份系統中一定會保存最近半個月的所有binlog，同時系統會定期做整庫備份。這裏的“定期”取决於系統的重要性，可以是一天一備，也可以是一周一備

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

sync_binlog 這個參數設置成 1 的時候，錶示每次事務的 binlog 都持久化到磁盤。這個參數我也建議你設置成 1，這樣可以保證 MySQL 异常重啟之後 binlog 不丟失.

sync_binlog 這個參數設置成 1 的時候，錶示每次事務的 binlog 都持久化到磁盤。這個參數我也建議你設置成 1，這樣可以保證 MySQL 异常重啟之後 binlog 不丟失.

總結

1. Redo log不是記錄數據頁“更新之後的狀態”，而是記錄這個頁 “做了什麼改動”
2. Binlog有兩種模式，statement 格式的話是記sql語句， row格式會記錄行的內容，記兩條，更
   新前和更新後都有

參考

mysql慢日志