一條SQL在MySQL體系結構內的執行流程:

注意只有查詢操作才會走查詢緩存，而表的結構和數據發生改變時將會清空查詢緩存。所以開啟查詢緩存的意義不大，8.0后已經廢棄了該功能。

一條update在存儲引擎內部的執行步驟如下:

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

SQL完整流程剖析：

1.首先客戶端通過tcp/ip發送一條sql語句到server層的SQL interface

2.SQL interface接到該請求后，先對該條語句進行解析，驗證權限是否匹配

3.驗證通過以后，分析器會對該語句分析,是否語法有錯誤等

4.接下來是優化器器生成相應的執行計劃，選擇最優的執行計劃

5.之后會是執行器根據執行計劃執行這條語句。在這一步會去open table,如果該table上有MDL，則等待。如果沒有，則加在該表上加短暫的MDL(S)

(如果opend_table太大,表明open_table_cache太小。需要不停的去打開frm文件)

6.進入到引擎層，首先會去innodb_buffer_pool里的data dictionary(元數據信息)得到表信息(實際上第5步調用了第6步的過程，mysql server層和innodb層都保存了表結構信息)

7.通過元數據信息,去lock info里查出是否會有相關的鎖信息，并把這條update語句需要的鎖信息寫入到lock info里

8.然后涉及到的老數據通過快照的方式存儲到innodb_buffer_pool里的undo page里,并且記錄undo log修改的redo

(如果data page里有就直接載入到undo page里，如果沒有，則需要去磁盤里取出相應page的數據，載入到undo page里)

9.在innodb_buffer_pool的data page做update操作。并把操作的物理數據頁修改記錄到redo log buffer里。

由于update這個事務會涉及到多個頁面的修改，所以redo log buffer里會記錄多條頁面的修改信息。

因為group commit的原因，這次事務所產生的redo log buffer可能會跟隨其它事務一同flush并且sync到磁盤上

10.同時修改的信息，會按照event的格式,記錄到binlog_cache中。(這里注意binlog_cache_size是transaction級別的,不是session級別的參數,

一旦commit之后，dump線程會從binlog_cache里把event主動發送給slave的I/O線程)

11.之后把這條sql,需要在二級索引上做的修改，寫入到change buffer page，等到下次有其他sql需要讀取該二級索引時，再去與二級索引做merge

(隨機I/O變為順序I/O,但是由于現在的磁盤都是SSD,所以對于尋址來說,隨機I/O和順序I/O差距不大)

12.此時update語句已經完成，需要commit或者rollback。這里討論commit的情況，并且雙1

13.commit操作，由于存儲引擎層與server層之間采用的是內部XA(保證兩個事務的一致性,這里主要保證redolog和binlog的原子性),所以提交分為prepare階段與commit階段

14.prepare階段,生成xid,持有prepare_commit_mutex鎖，并且write/sync redo log；將回滾段設置為Prepared狀態，binlog不作任何操作。

15.commit階段，由于之前該事務產生的redolog已經sync到磁盤了。所以這步write/sync Binlog，并且在redo log里標記commit，最后釋放prepare_commit_mutex

16.當binlog和redo log都已經落盤以后，如果觸發了刷新臟頁的操作，先把該臟頁復制到doublewrite buffer里，把doublewrite buffer里的刷新到共享表空間，然后才是通過page cleaner線程把臟頁寫入到磁盤中

總結

以上是生活随笔為你收集整理的mysql内部_MySQL SQL语句内部剖析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。