Mysql的邏輯架構如下圖所示，整體分成兩個部分，Server層和儲存引擎層。
與儲存引擎無關的操作都是在Server層完成的，儲存引擎層負責資料的存取。
以下將會依照上圖的過程分別介紹每一步的作用，這裡以查詢一筆記錄為例。
這一步主要是管理連線和權限驗證。
負責管理客戶端的連接，例如mysql -u root -p，就是客戶端與連接器之間完成的，連接分為長連接和短連接，建議使用長連接，因為建立連結是相對複雜的一個過程。但長連接也有最佳化的空間，即長連接過多，隨著執行大的查詢操作，會佔用較多的記憶體。
建立連線完成之後，連接器會判斷該使用者的權限，之後使用者的操作都會基於權限來判定是否允許。
這一步驟主要是詞法分析和語法分析。
詞法分析主要是判定使用者想做什麼，例如select 就是想要查詢。
語法分析主要是判斷使用者輸入的SQL是否符合Mysql的語法。
經過分析器，Mysql已經知道用戶想要做什麼了，但是對於相同的一條SQL語句，對於Mysql具體實施的時候，可能有多種方法去實現，效率就不一樣。
在最佳化器這一步，mysql需要判定怎麼樣執行才是最優的效率。
這一步主要是操作引擎和回傳結果。操作儲存引擎層以遍歷資料表，尋找符合條件的資料並傳回給客戶端。
與一條SQL查詢語句相同的是，在Mysql中同樣要經過連接器、分析器、優化器、執行器，也要用到儲存引擎來進行資料的存取。
不同的是，更新語句需要涉及兩個重要的日誌模組，redo log和binlog
一家飯店生意紅火，但作為一家飯店來說，免不了每天都有賒帳和來還帳的。
如果有大量的賒帳和還帳的人，老闆將無法用一塊粉板來記錄一個月的賒帳記錄。
所以老闆想到可以把所有的賒帳記錄寫到帳本上，而粉板上寫的都是短時間的，等下班了之後，拿粉板上的和賬本進行對賬。
在這個例子中，粉板就是redo log，帳本就是mysql中的記錄，我們用還帳類比一下mysql的更新過程，如果每次有人更新，我們都去mysql中找到這條記錄，效率很低，所以mysql的思路和這個老闆一致，更新操作先放到redo log中，過一段時間再慢慢消化。
這種想法叫做WAL技術，也就是Write Ahead Logging技術，先寫日誌，再寫磁碟。
老闆必須停下手邊的工作，如果粉板已經滿了而且老闆還沒下班。 mysql中的redo log總共可以記錄4GB的操作
當write pos 追上check point，mysql這個老闆就要去處理一下redo log了。
除此之外，有了redo log持久化，資料庫即使異常重啟也不會遺失日誌，這是crash safe機制，但仍需要注意的是，redo log是innodb儲存引擎特有的。
binlog是Server層的日誌，可以適用於所有儲存引擎。
那既然有binlog了，前文為什麼要搞innodb儲存引擎專屬的redo log呢？
因為mysql最開始沒有innodb引擎，而是myisam引擎，使用的是binlog，但是binlog僅限於歸檔，沒有crash safe機制，於是自己補充了一個redo log。
redo log是innodb儲存引擎特有的，而binlog是server層特有的
redo log儲存的是實體日誌，binlog是邏輯日誌
redo log像上面講的那樣，支援4GB大小，多了就得處理並且去覆蓋，binlog日誌當寫滿一個日誌
檔案之後，會新建一個新的日誌檔。
下面以更新ID為2的一行資料為例：
圖中淺色框表示是在InnoDB 內部執行的，深色框表示是在執行器中執行的。
執行器先找引擎取 ID=2 這一行。 ID 是主鍵，引擎直接用樹搜尋找到這一行。如果 ID=2 這一行所在的資料頁本來就在內存中，就直接返回給執行器；否則，需要先從磁碟讀入內存，然後再返回。
執行器拿到引擎給的行數據，把這個值加上1，例如原來是N，現在就是N 1，得到新的一行數據，再呼叫引擎介面寫入這行新數據。
引擎將這行新資料更新到記憶體中，同時將這個更新操作記錄到 redo log 裡面，此時 redo log 處於 prepare 狀態。然後告知執行器執行完成了，隨時可以提交事務。在執行操作過程中，執行器會產生一個 binlog 並將其寫入磁碟。
執行器呼叫引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成。
以上是Mysql執行一條語句的整個過程是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
