最近有粉絲面試互聯網公司被問到：你知道select語句和update語句分別是怎麼執行的嗎？，要我寫一篇這二者執行SQL語句的區別，這不就來了。mysql
總的來講，select和update執行的邏輯大致同樣，可是具體的實現仍是有區別的。web
固然深刻了解select和update的具體區別並非只爲了面試，當但願Mysql可以高效的執行的時候，最好的辦法就是清楚的瞭解Mysql是如何執行查詢的，只有更加全面的瞭解SQL執行的每個過程，才能更好的進行SQl的優化。面試
select語句
當執行一條查詢的SQl的時候大概發生了以下的步驟：sql
-
客戶端發送查詢語句給服務器。 -
服務器首先進行用戶名和密碼的驗證以及權限的校驗。 -
而後會檢查緩存中是否存在該查詢，若存在，返回緩存中存在的結果。如果不存在就進行下一步。 -
接着進行語法和詞法的分析，對SQl的解析、語法檢測和預處理，再由優化器生成對應的執行計劃。 -
Mysql的執行器根據優化器生成的執行計劃執行，調用存儲引擎的接口進行查詢。 -
服務器將查詢的結果返回客戶端。
執行的流程
Mysql中語句的執行都是都是分層執行，每一層執行的任務都不一樣，直到最後拿到結果返回，主要分爲Service層和引擎層，在Service層中包含：鏈接器、分析器、優化器、執行器。引擎層以插件的形式能夠兼容各類不一樣的存儲引擎。數據庫
Mysql的執行的流程圖以下圖所示：這裏以一個實例進行說明Mysql的的執行過程，新建一個User表，以下：緩存
// 新建一個表
DROP TABLE IF EXISTS User;
CREATE TABLE `User` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(10) DEFAULT NULL,
`age` int DEFAULT 0,
`address` varchar(255) DEFAULT NULL,
`phone` varchar(255) DEFAULT NULL,
`dept` int,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=40 DEFAULT CHARSET=utf8;
// 並初始化數據，以下
INSERT INTO User(name,age,address,phone,dept)VALUES('張三',24,'北京','13265543552',2);
INSERT INTO User(name,age,address,phone,dept)VALUES('張三三',20,'北京','13265543557',2);
INSERT INTO User(name,age,address,phone,dept)VALUES('李四',23,'上海','13265543553',2);
INSERT INTO User(name,age,address,phone,dept)VALUES('李四四',21,'上海','13265543556',2);
INSERT INTO User(name,age,address,phone,dept)VALUES('王五',27,'廣州','13265543558',3);
INSERT INTO User(name,age,address,phone,dept)VALUES('王五五',26,'廣州','13265543559',3);
INSERT INTO User(name,age,address,phone,dept)VALUES('趙六',25,'深圳','13265543550',3);
INSERT INTO User(name,age,address,phone,dept)VALUES('趙六六',28,'廣州','13265543561',3);
INSERT INTO User(name,age,address,phone,dept)VALUES('七七',29,'廣州','13265543562',4);
INSERT INTO User(name,age,address,phone,dept)VALUES('八八',23,'廣州','13265543563',4);
INSERT INTO User(name,age,address,phone,dept)VALUES('九九',24,'廣州','13265543564',4);
如今針對這個表發出一條SQl查詢：查詢每一個部門中25歲如下的員工個數大於3的員工個數和部門編號，並按照人工個數降序排序和部門編號升序排序的前兩個部門。性能優化
SELECT dept,COUNT(phone) AS num FROM User WHERE age< 25 GROUP BY dept HAVING num >= 3 ORDER BY num DESC,dept ASC LIMIT 0,2;
鏈接器
開始執行這條sql時，首先會校驗你的用戶名和密碼是否正確，如果不正確會返回錯誤信息："Access denied for user"；服務器
如果用戶名和密碼校驗經過，而後就會到權限表獲取當前用戶擁有的權限，會檢查該語句是否有權限，如果沒有權限就直接返回錯誤信息，有權限會進行下一步，校驗權限的這一步是在圖一的鏈接器進行的，對鏈接用戶權限的校驗。微信
注意：後續的一些列操做都是依賴於這個權限的範圍內的。hexo
檢索緩存
當創建鏈接，履行查詢語句的時候，會先行檢查在緩存區域看看這個sql與否履行過，如果以前執行過，它的執行結果會以Key-Value的形式緩存於內存中，Key是執行的sql，Value是結果集。
假如，緩存中key遭擊中，便會直接將結果返回給客戶端，假如沒命中，便會履行後續的操做，完工以後亦會將結果緩存起來以便再次查詢獲取，當下一次進行查詢的時候也是如此的循環操做。
注意：Mysql中的緩存比較適合於那些靜態的表，更新不頻繁的表，由於只要當前表有數據更新，有關於該表的緩存就會失效，如果表更新頻繁緩存頻繁的失效，這樣維護緩存的消耗的性能遠大於使用緩存帶來的性能優化，這樣就會得不償失，嚴重影響Mysql的性能，因此在Mysql 8版本中的時候把緩存這一塊給砍掉了。
在我的的觀點中對於緩存這一塊的見解是，不必砍掉，能夠設置成默認關閉緩存，須要的時候再設置開啓，而且能夠經過配置參數指定特定的表使用緩存，那些表不使用緩存，這樣或許使用緩存更有效。
分析器
分析器主要有兩步：（1）詞法分析（2）語法分析
詞法分析主要執行提煉關鍵性字，好比select，提交檢索的表，提交字段名，提交檢索條件，肯定該語句是select仍是update或者是delete語句。
語法分析主要執行辨別你輸出的sql與否準確，是否合乎mysql的語法，如果不符合sql語法就會拋出：You have an error in your SQL syntax。
優化器
查詢優化器會將解析樹轉化成執行計劃。一條查詢能夠有多種執行方法，最後都是返回相同結果。優化器的做用就是找到這其中最好的執行計劃。
例如：在查詢語句中有多個索引的時候，優化器決定使用哪個索引，或者有多表關聯的時候，決定表的鏈接順序等這些操做都是在優化器決定的。
生成執行計劃的過程會消耗較多的時間，特別是存在許多可選的執行計劃時。若是在一條SQL語句執行的過程當中將該語句對應的最終執行計劃進行緩存。
當類似的語句再次被輸入服務器時，就能夠直接使用已緩存的執行計劃，從而跳過SQL語句生成執行計劃的整個過程，進而能夠提升語句的執行速度。
MySQL使用基於成本的查詢優化器。它會嘗試預測一個查詢使用某種執行計劃時的成本，並選擇其中成本最少的一個。
執行器
優化器生成得執行計劃，交由執行器進行執行，執行器調用存儲引擎得讀接口，執行器中循環的調用存儲引擎的讀接口，以此換取知足條件的數據行，並把它放在一個結果集中，遍歷並獲取了全部知足條件的數據行，最後將結果集返回，結束整個查詢得過程。
update語句
上面咱們說完了select語句，select語句的執行過程會通過鏈接器、分析器、優化器、執行器、存儲引擎，一樣的update語句也會一樣走一遍select語句的執行過程。
可是和select最大不一樣的是，update語句會涉及到兩個日誌的操做redo log（重作日誌） 和binlog （歸檔日誌）。對於這兩個日誌的詳細介紹，我以前寫過一篇文章進行介紹，有興趣的能夠看一看[]：
那麼Mysql中又是怎麼使用redo log和binlog？爲何要使用redo log和binlog呢？直接執行更新而後存庫不就好了嗎？還要放在redo log和binlog中，這不是畫蛇添足嗎？且聽我慢慢道來，這裏面大有文章。
redo log
你們都是知道Mysql是關係型數據庫，用來存儲數據的，在訪問數據庫量大的時候，Mysql讀寫磁盤訪問的效率是很是低的，加上sql中的條件對數據的篩選過濾，那麼效率就更低了。
這也是爲何引入非關係型數據庫做爲做爲數據緩存緣由，例如：Redis、MongoDB等，就是爲了減小sql執行期間的數據庫io操做。
一樣的道理，如果每次執行update語句都要進行磁盤的io操做、以及數據的過濾篩選，小量的訪問和數據量數據庫還能夠撐住，那麼訪問量一大以及數據量一大，這樣數據庫確定頂不住。
基於上面的問題因而出現了redo log日誌，redo log日誌也叫作WAL技術（Write- Ahead Logging），他是一種先寫日誌，並更新內存，最後再更新磁盤的技術，而且更新磁盤每每是在Mysql比較閒的時候，這樣就大大減輕了Mysql的壓力。
redo log的特色就是：redo log是固定大小，是物理日誌，屬於InnoDB引擎的，而且寫redo log是環狀寫日誌的形式：
如上圖所示：如果四組的redo log文件，一組爲1G的大小，那麼四組就是4G的大小，其中write pos是記錄當前的位置，有數據寫入當前位置，那麼write pos就會邊寫入邊日後移。
而check point是擦除的位置，由於redo log是固定大小，因此當redo log滿的時候，也就是write pos追上check point的時候，須要清除redo log的部分數據，清除的數據會被持久化到磁盤中，而後將check point向前移動。
redo log日誌實現了即便在數據庫出現異常宕機的時候，重啓後以前的記錄也不會丟失，這就是crash-safe能力。
binlog
binlog稱爲歸檔日誌，是邏輯上的日誌，它屬於Mysql的Server層面的日誌，記錄着sql的原始邏輯，主要有兩種模式，一個是statement格式記錄的是原始的sql，而row格式則是記錄行內容。
那麼這樣看來redo log和binlog雖然記錄的形式、內容不一樣，可是這二者日誌都能經過本身記錄的內容恢復數據，那麼爲何還要這兩個日誌同時存在呢？只要其中一個不就好了嘛，兩個同時存在不就畫蛇添足了嘛。且聽我慢慢道來，這裏面也大有文章。
由於剛開Mysql自帶的引擎MyISAM就沒有crash-safe功能的，而且在此以前Mysql尚未InnoDB引擎，Mysql自帶的binlog日誌只是用來歸檔日誌的，因此InnoDB引擎也就經過本身redo log日誌來實現crash-safe功能。
update執行過程
上面說了那麼久兩種日誌的做用和特色，那麼這兩種日誌究竟和update執行語句有什麼關係呢？
先來看圖：
前提：當前的引擎是使用InnoDB，update語句與select語句區別主要是這兩日誌的使用主要是在執行器和引擎之間進行交互時體現的區別。假如執行以下一條簡單的更新語句是：
update user set age=age+1 where id =2；
上面說過select語句走過的流程update語句也會走一遍，當來到執行器的時候：
-
執行器會調用引擎的讀接口，而後找到id=2的數據行，由於id是主鍵索引，索引按照樹的搜索找到這一行， 如果數據行已經存在於內存的數據頁中就會當即將結果返回，如果不在內存中，就會從磁盤中進行加載到內存中，而後將查詢的結果返回。 -
而後，執行器將返回的結果的age字段+1，並調用引擎的寫接口寫入更新後的數據行。 -
引擎獲取到更新後的數據行更新到內存和 redo log中，並告訴執行器能夠隨時提交事務，此時的redo log處於prepare階段。 -
執行器收到引擎的告知後，生成 binlog日誌，而且調用引擎的接口提交事務，引擎將redo log的狀態修改成commit狀態，這樣這個更新操做算是完成。
與select語句相比，由於select沒有更新數據，只是將引擎查詢的數據返回給執行器就算是完後，而update涉及數據的更新而且從新調用引擎接口寫會存儲引擎中的交互過程。
兩階段提交
上面詳細的說了update語句的執行流程，提到了redo log的prepare和commit兩個階段，這就是兩階段提交，兩階段提交的目的是爲了保證redo log日誌與binlog日誌保持數據的一致性。
如果redo log寫成功binlog寫失敗，或者redo log寫失敗binlog寫成功，最後使用這二者日誌進行數據恢復獲得的結果數據都是不一致性的，因此爲了保證兩個日誌邏輯上的一致，使用兩階段進行提交。
redo log與binlog的總結
最後來對比一下這兩種日誌：redo是物理的，binlog是邏輯的，redo的大小固定，而且以環狀的形式寫入數據，數據滿的時候須要將redo日誌中擦除數據，而且將擦除的數據持久化到磁盤中。
而binlog以追加日誌的形式寫入，也就是當日志寫到必定大小後，就會切換到下一個，並不會覆蓋之前寫的日誌。
binlog是在Mysql的Server層中使用，由於binlog沒有crash-safe功能，因此InnoDB引擎本身實現了redo log日誌的crash-safe的功能，爲了保證這兩個日誌邏輯上的一導致用兩階段提交。
在使用redo和binlog這兩種日誌的時候，能夠將參數innodb_flush_log_at_trx_commit和sync_binlog都設置爲1，它表示每次事務提交的時候，都會將日誌持久化到磁盤中。
好了，這裏詳細的介紹了select和update執行語句的區別，這一期就到這裏，咱們下一期間，喜歡的歡迎轉發和分享。
有熱門推薦👇
有熱門推薦👇
本文分享自微信公衆號 - 非科班的科班（LDCldc123095）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。