一條SQL語句在MySQL中是如何執行的

前言

最近開始在學習mysql相關知識,本身根據學到的知識點,根據本身的理解整理分享出來,本篇文章會分析下一個sql語句在mysql中的執行流程,包括sql的查詢在mysql內部會怎麼流轉,sql語句的更新是怎麼完成的。在分析以前我會先帶着你看看 MySQL 的基礎架構,知道了 MySQL 由那些組件組成已經這些組件的做用是什麼,能夠幫助咱們理解和解決這些問題。mysql

1、mysql架構分析

下面是mysql的一個簡要架構圖:算法

mysql主要分爲Server層和存儲引擎層sql

Server層:主要包括鏈接器、查詢緩存、分析器、優化器、執行器等,全部跨存儲引擎的功能都在這一層實現,好比存儲過程、觸發器、視圖,函數等,還有一個通用的日誌模塊 binglog日誌模塊。數據庫

存儲引擎: 主要負責數據的存儲和讀取,採用能夠替換的插件式架構,支持InnoDB、MyISAM、Memory等多個存儲引擎,其中InnoDB引擎有自有的日誌模塊redolog 模塊。緩存

InnoDB 5.5.5版本做爲默認引擎。bash

鏈接器架構

主要負責用戶登陸數據庫,進行用戶的身份認證,包括校驗帳戶密碼,權限等操做,若是用戶帳戶密碼已經過,鏈接器會到權限表中查詢該用戶的全部權限,以後在這個鏈接裏的權限邏輯判斷都是會依賴此時讀取到的權限數據,也就是說,後續只要這個鏈接不斷開,即時管理員修改了該用戶的權限,該用戶也是不受影響的。函數

查詢緩存學習

鏈接創建後,執行查詢語句的時候,會先查詢緩存,Mysql會先校驗這個sql是否執行過,以Key-Value的形式緩存在內存中,Key是查詢預計,Value是結果集。若是緩存key被命中,就會直接返回給客戶端,若是沒有命中,就會執行後續的操做,完成後也會把結果緩存起來,方便下一次調用。固然在真正執行緩存查詢的時候仍是會校驗用戶的權限,是否有該表的查詢條件。優化

Mysql 查詢不建議使用緩存,由於對於常常更新的數據來講,緩存的有效時間過短了,每每帶來的效果並很差,對於不常常更新的數據來講,使用緩存仍是能夠的,Mysql 8.0 版本後刪除了緩存的功能,官方也是認爲該功能在實際的應用場景比較少,因此乾脆直接刪掉了。

分析器

mysql 沒有命中緩存,那麼就會進入分析器,分析器主要是用來分析SQL語句是來幹嗎的,分析器也會分爲幾步:

第一步,詞法分析,一條SQL語句有多個字符串組成,首先要提取關鍵字,好比select,提出查詢的表,提出字段名,提出查詢條件等等。作完這些操做後,就會進入第二步。

第二步,語法分析,主要就是判斷你輸入的sql是否正確,是否符合mysql的語法。

完成這2步以後,mysql就準備開始執行了,可是如何執行,怎麼執行是最好的結果呢?這個時候就須要優化器上場了。

優化器

優化器的做用就是它認爲的最優的執行方案去執行(雖然有時候也不是最優),好比多個索引的時候該如何選擇索引,多表查詢的時候如何選擇關聯順序等。

執行器

當選擇了執行方案後,mysql就準備開始執行了,首先執行前會校驗該用戶有沒有權限,若是沒有權限,就會返回錯誤信息,若是有權限,就會去調用引擎的接口,返回接口執行的結果。

2、語句分析

2.1 查詢語句

說了以上這麼多,那麼究竟一條sql語句是如何執行的呢?其實咱們的sql能夠分爲兩種,一種是查詢,一種是更新(增長,更新,刪除)。咱們先分析下查詢語句,語句以下:

select * from tb_student  A where A.age='18' and A.name='張三';

複製代碼

結合上面的說明,咱們分析下這個語句的執行流程:

  • 先檢查該語句是否有權限,若是沒有權限,直接返回錯誤信息,若是有權限,在mysql8.0版本之前,會先查詢緩存,以這條sql語句爲key在內存中查詢是否有結果,若是有直接緩存,若是沒有,執行下一步。

  • 經過分析器進行詞法分析,提取sql語句的關鍵元素,好比提取上面這個語句是查詢select,提取須要查詢的表名爲tb_student,須要查詢全部的列,查詢條件是這個表的id='1'。而後判斷這個sql語句是否有語法錯誤,好比關鍵詞是否正確等等,若是檢查沒問題就執行下一步。

  • 接下來就是優化器進行肯定執行方案,上面的sql語句,能夠有兩種執行方案:

    a.先查詢學生表中姓名爲「張三」的學生,而後判斷是否年齡是18。
      b.先找出學生中年齡18歲的學生,而後再查詢姓名爲「張三」的學生。
    複製代碼

    那麼優化器根據本身的優化算法進行選擇執行效率最好的一個方案(優化器認爲,有時候不必定最好)。那麼確認了執行計劃後就準備開始執行了。

  • 進行權限校驗,若是沒有權限就會返回錯誤信息,若是有權限就會調用數據庫引擎接口,返回引擎的執行結果。

2.2 更新語句

以上就是一條查詢sql的執行流程,那麼接下來咱們看看一條更新語句如何執行的呢?sql語句以下:

update tb_student A set A.age='19' where A.name='張三';
複製代碼

咱們來給張三修改下年齡,在實際數據庫確定不會設置年齡這個字段的,否則要被技術負責人打的。其實條語句也基本上會沿着上一個查詢的流程走,只不過執行更新的時候確定要記錄日誌啦,這就會引入日誌模塊了,mysql 自帶的日誌模塊式binlog(歸檔日誌),全部的存儲引擎均可以使用,咱們經常使用的InnoDB引擎還自帶了一個日誌模塊redo log,咱們就以InnoDB模式下來探討這個語句的執行流程。流程以下:

  • 先查詢到張三這一條數據,若是有緩存,也是會用到緩存。
  • 而後拿到查詢的語句,把 age 改成19,而後調用引擎API接口,寫入這一行數據,InnoDB引擎把數據保存在內存中,同時記錄redo log,此時redo log進入prepare狀態,而後告訴執行器,執行完成了,隨時能夠提交。
  • 執行器收到通知後記錄binlog,而後調用引擎接口,提交redo log 爲提交狀態。
  • 更新完成。

這裏確定有同窗會問,爲何要用兩個日誌模塊,用一個日誌模塊不行嗎?這就是以前mysql的模式了,MyISAM引擎是沒有redo log的,那麼咱們知道它是不支持事務的,因此並非說只用一個日誌模塊不能夠,只是InnoDB引擎就是經過redo log來支持事務的。那麼,又會有同窗問,我用兩個日誌模塊,可是不要這麼複雜行不行,爲何redo log 要引入prepare預提交狀態?這裏咱們用反證法來講明下爲何要這麼作?

  • 先寫redo log 直接提交,而後寫 binlog,假設寫完redo log 後,機器掛了,binlog日誌沒有被寫入,那麼機器重啓後,這臺機器會經過redo log恢復數據,可是這個時候bingog並無記錄該數據,後續進行機器備份的時候,就會丟失這一條數據,同時主從同步也會丟失這一條數據。
  • 先寫binlog,而後寫redo log,假設寫完了binlog,機器異常重啓了,因爲沒有redo log,本機是沒法恢復這一條記錄的,可是binlog又有記錄,那麼和上面一樣的道理,就會產生數據不一致的狀況。

若是採用redo log 兩階段提交的方式就不同了,寫完binglog後,而後再提交redo log就會防止出現上述的問題,從而保證了數據的一致性。那麼問題來了,有沒有一個極端的狀況呢?假設redo log 處於預提交狀態,binglog也已經寫完了,這個時候發生了異常重啓會怎麼樣呢? 這個就要依賴於mysql的處理機制了,mysql的處理過程以下:

  • 判斷redo log 是否完整,若是判斷是完整的,就當即提交。
  • 若是redo log 只是預提交但不是commit狀態,這個時候就會去判斷binlog是否完整,若是完整就提交 redo log, 不完整就回滾事務。

這樣就解決了數據一致性的問題。

3、總結

  • Mysql 主要分爲Server曾和引擎層,Server層主要包括鏈接器、查詢緩存、分析器、優化器、執行器,同時還有一個日誌模塊(binlog),這個日誌模塊全部執行引擎均可以共用。
  • 引擎層是插件式的,目前主要包括,MyISAM,InnoDB,Memory等。
  • 查詢語句的執行流程以下:權限校驗(若是命中緩存)---》查詢緩存---》分析器---》優化器---》權限校驗---》執行器---》引擎
  • 更新語句執行流程以下:分析器----》權限校驗----》執行器---》引擎---redo log(prepare 狀態---》binlog---》redo log(commit狀態)

4、參考

相關文章
相關標籤/搜索