前言

天天和資料庫打交道，一天能寫上幾十條 SQL 語句，但你知道我們的系統是如何和資料庫互動的嗎？MySQL 如何幫我們儲存資料、又是如何幫我們管理事務？....是不是感覺真的除了寫幾個 「select * from dual」外基本腦子一片空白？這篇文章就將帶你走進 MySQL 的世界，讓你徹底瞭解系統到底是如何和 MySQL 互動的，MySQL 在接受到我們傳送的 SQL 語句時又分別做了哪些事情。

¶ MySQL 驅動

我們的系統在和 MySQL 資料庫進行通訊的時候，總不可能是平白無故的就能接收和傳送請求，就算是你沒有做什麼操作，那總該是有其他的“人”幫我們做了一些事情，基本上使用過 MySQL 資料庫的程式設計師多多少少都會知道 MySQL 驅動這個概念的。就是這個 MySQL 驅動在底層幫我們做了對資料庫的連線，只有建立了連線了，才能夠有後面的互動。看下圖表示

這樣的話，在系統和 MySQL 進行互動之前，MySQL 驅動會幫我們建立好連線，然後我們只需要傳送 SQL 語句就可以執行 CRUD 了。一次 SQL 請求就會建立一個連線，多個請求就會建立多個連線，那麼問題來了，我們系統肯定不是一個人在使用的，換句話說肯定是存在多個請求同時去爭搶連線的情況。我們的 web 系統一般都是部署在 tomcat 容器中的，而 tomcat 是可以併發處理多個請求的，這就會導致多個請求會去建立多個連線，然後使用完再都去關閉，這樣會有什麼問題呢？如下圖

java 系統在通過 MySQL 驅動和 MySQL 資料庫連線的時候是基於 TCP/IP 協議的，所以如果每個請求都是新建連線和銷燬連線，那這樣勢必會造成不必要的浪費和效能的下降，也就說上面的多執行緒請求的時候頻繁的建立和銷燬連線顯然是不合理的。必然會大大降低我們系統的效能，但是如果給你提供一些固定的用來連線的執行緒，這樣是不是不需要反覆的建立和銷燬連線了呢？相信懂行的朋友會會心一笑，沒錯，說的就是資料庫連線池。

資料庫連線池：維護一定的連線數，方便系統獲取連線，使用就去池子中獲取，用完放回去就可以了，我們不需要關心連線的建立與銷燬，也不需要關心執行緒池是怎麼去維護這些連線的。

常見的資料庫連線池有 Druid、C3P0、DBCP，連線池實現原理在這裡就不深入討論了，採用連線池大大節省了不斷建立與銷燬執行緒的開銷，這就是有名的「池化」思想，不管是執行緒池還是 HTTP 連線池，都能看到它的身影。

¶ 資料庫連線池

到這裡，我們已經知道的是我們的系統在訪問 MySQL 資料庫的時候，建立的連線並不是每次請求都會去建立的，而是從資料庫連線池中去獲取，這樣就解決了因為反覆的建立和銷燬連線而帶來的效能損耗問題了。不過這裡有個小問題，業務系統是併發的，而 MySQL 接受請求的執行緒呢，只有一個？

其實 MySQL 的架構體系中也已經提供了這樣的一個池子，也是資料庫連池。雙方都是通過資料庫連線池來管理各個連線的，這樣一方面執行緒之前不需要是爭搶連線，更重要的是不需要反覆的建立的銷燬連線。

至此係統和 MySQL 資料庫之間的連線問題已經說明清楚了。那麼 MySQL 資料庫中的這些連線是怎麼來處理的，又是誰來處理呢？

¶ 網路連線必須由執行緒來處理

對計算基礎稍微有一點了解的的同學都是知道的，網路中的連線都是由執行緒來處理的，所謂網路連線說白了就是一次請求，每次請求都會有相應的執行緒去處理的。也就是說對於 SQL 語句的請求在 MySQL 中是由一個個的執行緒去處理的。

那這些執行緒會怎麼去處理這些請求？會做哪些事情？

¶ SQL 介面

MySQL 中處理請求的執行緒在獲取到請求以後獲取 SQL 語句去交給 SQL 介面去處理。

¶ 查詢解析器

假如現在有這樣的一個 SQL

SELECT stuName,age,sex FROM students WHERE id=1

現在 SQL 已經被解析成 MySQL 認識的樣子的，那下一步是不是就是執行嗎？理論上是這樣子的，但是 MySQL 的強大遠不止於此，他還會幫我們選擇最優的查詢路徑。

什麼叫最優查詢路徑？就是 MySQL 會按照自己認為的效率最高的方式去執行查詢.

具體是怎麼做到的呢？這就要說到 MySQL 的查詢優化器了

¶ MySQL 查詢優化器

查詢優化器內部具體怎麼實現的我們不需要是關心，我需要知道的是 MySQL 會幫我去使用他自己認為的最好的方式去優化這條 SQL 語句，並生成一條條的執行計劃，比如你建立了多個索引，MySQL 會依據成本最小原則來選擇使用對應的索引，這裡的成本主要包括兩個方面, IO 成本和 CPU 成本

IO 成本: 即從磁碟把資料載入到記憶體的成本，預設情況下，讀取資料頁的 IO 成本是 1，MySQL 是以頁的形式讀取資料的，即當用到某個資料時，並不會只讀取這個資料，而會把這個資料相鄰的資料也一起讀到記憶體中，這就是有名的程式區域性性原理，所以 MySQL 每次會讀取一整頁，一頁的成本就是 1。所以 IO 的成本主要和頁的大小有關

CPU 成本：將資料讀入記憶體後，還要檢測資料是否滿足條件和排序等 CPU 操作的成本，顯然它與行數有關，預設情況下，檢測記錄的成本是 0.2。

MySQL 優化器 會計算 「IO 成本 + CPU」 成本最小的那個索引來執行

優化器執行選出最優索引等步驟後，會去呼叫儲存引擎介面，開始去執行被 MySQL 解析過和優化過的 SQL 語句

¶ 儲存引擎

查詢優化器會呼叫儲存引擎的介面，去執行 SQL，也就是說真正執行 SQL 的動作是在儲存引擎中完成的。資料是被存放在記憶體或者是磁碟中的（儲存引擎是一個非常重要的元件，後面會詳細介紹）

¶ 執行器

執行器是一個非常重要的元件，因為前面那些元件的操作最終必須通過執行器去呼叫儲存引擎接口才能被執行。執行器最終最根據一系列的執行計劃去呼叫儲存引擎的介面去完成 SQL 的執行

¶ 初識儲存引擎

我們以一個更新的SQL語句來說明，SQL 如下

UPDATE students SET stuName = '小強' WHERE id = 1

當我們系統發出這樣的查詢去交給 MySQL 的時候，MySQL 會按照我們上面介紹的一系列的流程最終通過執行器呼叫儲存引擎去執行，流程圖就是上面那個。在執行這個 SQL 的時候 SQL 語句對應的資料要麼是在記憶體中，要麼是在磁碟中，如果直接在磁碟中操作，那這樣的隨機IO讀寫的速度肯定讓人無法接受的，所以每次在執行 SQL 的時候都會將其資料載入到記憶體中，這塊記憶體就是 InnoDB 中一個非常重要的元件：緩衝池 Buffer Pool

¶ Buffer Pool

Buffer Pool （緩衝池）是 InnoDB 儲存引擎中非常重要的記憶體結構，顧名思義，緩衝池其實就是類似 Redis 一樣的作用，起到一個快取的作用，因為我們都知道 MySQL 的資料最終是儲存在磁碟中的，如果沒有這個 Buffer Pool 那麼我們每次的資料庫請求都會磁碟中查詢，這樣必然會存在 IO 操作，這肯定是無法接受的。但是有了 Buffer Pool 就是我們第一次在查詢的時候會將查詢的結果存到 Buffer Pool 中，這樣後面再有請求的時候就會先從緩衝池中去查詢，如果沒有再去磁碟中查詢，然後在放到 Buffer Pool 中，如下圖

按照上面的那幅圖，這條 SQL 語句的執行步驟大致是這樣子的

• innodb 儲存引擎會在緩衝池中查詢 id=1 的這條資料是否存在
• 發現不存在，那麼就會去磁碟中載入，並將其存放在緩衝池中
• 該條記錄會被加上一個獨佔鎖（總不能你在修改的時候別人也在修改吧，這個機制本篇文章不重點介紹，以後會專門寫文章來詳細講解）

¶ undo 日誌檔案：記錄資料被修改前的樣子

undo 顧名思義，就是沒有做，沒發生的意思。undo log 就是沒有發生事情（原本事情是什麼）的一些日誌

我們剛剛已經說了，在準備更新一條語句的時候，該條語句已經被載入到 Buffer pool 中了，實際上這裡還有這樣的操作，就是在將該條語句載入到 Buffer Pool 中的時候同時會往 undo 日誌檔案中插入一條日誌，也就是將 id=1 的這條記錄的原來的值記錄下來。

這樣做的目的是什麼？

Innodb 儲存引擎的最大特點就是支援事務，如果本次更新失敗，也就是事務提交失敗，那麼該事務中的所有的操作都必須回滾到執行前的樣子，也就是說當事務失敗的時候，也不會對原始資料有影響，看圖說話

這裡說句額外話，其實 MySQL 也是一個系統，就好比我們平時開發的 java 的功能系統一樣，MySQL 使用的是自己相應的語言開發出來的一套系統而已，它根據自己需要的功能去設計對應的功能，它即然能做到哪些事情，那麼必然是設計者們當初這麼定義或者是根據實際的場景變更演化而來的。所以大家放平心態，把 MySQL 當作一個系統去了解熟悉他。

到這一步，我們的執行的 SQL 語句已經被載入到 Buffer Pool 中了，然後開始更新這條語句，更新的操作實際是在Buffer Pool中執行的，那問題來了，按照我們平時開發的一套理論緩衝池中的資料和資料庫中的資料不一致時候，我們就認為快取中的資料是髒資料，那此時 Buffer Pool 中的資料豈不是成了髒資料？沒錯，目前這條資料就是髒資料，Buffer Pool 中的記錄是小強 資料庫中的記錄是旺財 ，這種情況 MySQL是怎麼處理的呢，繼續往下看

¶ redo 日誌檔案：記錄資料被修改後的樣子

除了從磁碟中載入檔案和將操作前的記錄儲存到 undo 日誌檔案中，其他的操作是在記憶體中完成的，記憶體中的資料的特點就是：斷電丟失。如果此時 MySQL 所在的伺服器宕機了，那麼 Buffer Pool 中的資料會全部丟失的。這個時候 redo 日誌檔案就需要來大顯神通了

畫外音：redo 日誌檔案是 InnoDB 特有的，他是儲存引擎級別的，不是 MySQL 級別的

redo 記錄的是資料修改之後的值，不管事務是否提交都會記錄下來，例如，此時將要做的是update students set stuName='小強' where id=1; 那麼這條操作就會被記錄到 redo log buffer 中，啥？怎麼又出來一個 redo log buffer ,很簡單，MySQL 為了提高效率，所以將這些操作都先放在記憶體中去完成，然後會在某個時機將其持久化到磁碟中。

截至目前，我們應該都熟悉了 MySQL 的執行器呼叫儲存引擎是怎麼將一條 SQL 載入到緩衝池和記錄哪些日誌的，流程如下：

• 準備更新一條 SQL 語句
• MySQL（innodb）會先去緩衝池（BufferPool）中去查詢這條資料，沒找到就會去磁碟中查詢，如果查詢到就會將這條資料載入到緩衝池（BufferPool）中
• 在載入到 Buffer Pool 的同時，會將這條資料的原始記錄儲存到 undo 日誌檔案中
• innodb 會在 Buffer Pool 中執行更新操作
• 更新後的資料會記錄在 redo log buffer 中

上面說的步驟都是在正常情況下的操作，但是程式的設計和優化並不僅是為了這些正常情況而去做的，也是為了那些臨界區和極端情況下出現的問題去優化設計的

這個時候如果伺服器宕機了，那麼快取中的資料還是丟失了。真煩，竟然資料總是丟失，那能不能不要放在記憶體中，直接儲存到磁碟呢？很顯然不行，因為在上面也已經介紹了，在記憶體中的操作目的是為了提高效率。

此時，如果 MySQL 真的宕機了，那麼沒關係的，因為 MySQL 會認為本次事務是失敗的，所以資料依舊是更新前的樣子，並不會有任何的影響。

好了，語句也更新好了那麼需要將更新的值提交啊，也就是需要提交本次的事務了，因為只要事務成功提交了，才會將最後的變更儲存到資料庫，在提交事務前仍然會具有相關的其他操作

將 redo Log Buffer 中的資料持久化到磁碟中，就是將 redo log buffer 中的資料寫入到 redo log 磁碟檔案中，一般情況下，redo log Buffer 資料寫入磁碟的策略是立即刷入磁碟（具體策略情況在下面小總結出會詳細介紹）,上圖

如果 redo log Buffer 刷入磁碟後，資料庫伺服器宕機了，那我們更新的資料怎麼辦？此時資料是在記憶體中，資料豈不是丟失了？不，這次資料就不會丟失了，因為 redo log buffer 中的資料已經被寫入到磁碟了，已經被持久化了，就算資料庫宕機了，在下次重啟的時候 MySQL 也會將 redo 日誌檔案內容恢復到 Buffer Pool 中（這邊我的理解是和 Redis 的持久化機制是差不多的，在 Redis 啟動的時候會檢查 rdb 或者是 aof 或者是兩者都檢查，根據持久化的檔案來將資料恢復到記憶體中）

到此為止，從執行器開始呼叫儲存引擎介面做了哪些事情呢？

• 準備更新一條 SQL 語句
• MySQL（innodb）會先去緩衝池（BufferPool）中去查詢這條資料，沒找到就會去磁碟中查詢，如果查詢到就會將這條資料載入
• 到緩衝池（BufferPool）中 3.在載入到 Buffer Pool 的同時，會將這條資料的原始記錄儲存到 undo 日誌檔案中
• innodb 會在 Buffer Pool 中執行更新操作
• 更新後的資料會記錄在 redo log buffer 中
• MySQL 提交事務的時候，會將 redo log buffer 中的資料寫入到 redo 日誌檔案中 刷磁碟可以通過 innodb_flush_log_at_trx_commit 引數來設定
  • 值為 0 表示不刷入磁碟
  • 值為 1 表示立即刷入磁碟
  • 值為 2 表示先刷到 os cache
• myslq 重啟的時候會將 redo 日誌恢復到緩衝池中

截止到目前位置，MySQL 的執行器呼叫儲存引擎的介面去執行【執行計劃】提供的 SQL 的時候 InnoDB 做了哪些事情也就基本差不多了，但是這還沒完。下面還需要介紹下 MySQL 級別的日誌檔案 bin log

¶ bin log 日誌檔案：記錄整個操作過程

上面介紹到的redo log是 InnoDB 儲存引擎特有的日誌檔案，而bin log屬於是 MySQL 級別的日誌。redo log記錄的東西是偏向於物理性質的，如：“對什麼資料，做了什麼修改”。bin log是偏向於邏輯性質的，類似於：“對 students 表中的 id 為 1 的記錄做了更新操作” 兩者的主要特點總結如下:

bin log檔案是如何刷入磁碟的?

bin log 的刷盤是有相關的策略的，策略可以通過sync_bin log來修改，預設為 0，表示先寫入 os cache，也就是說在提交事務的時候，資料不會直接到磁碟中，這樣如果宕機bin log資料仍然會丟失。所以建議將sync_bin log設定為 1 表示直接將資料寫入到磁碟檔案中。

刷入 bin log 有以下幾種模式

• STATMENT

基於 SQL 語句的複製(statement-based replication, SBR)，每一條會修改資料的 SQL 語句會記錄到 bin log 中

【優點】：不需要記錄每一行的變化，減少了 bin log 日誌量，節約了 IO , 從而提高了效能

【缺點】：在某些情況下會導致主從資料不一致，比如執行sysdate()、slepp()等

• ROW

基於行的複製(row-based replication, RBR)，不記錄每條SQL語句的上下文資訊，僅需記錄哪條資料被修改了

【優點】：不會出現某些特定情況下的儲存過程、或 function、或 trigger 的呼叫和觸發無法被正確複製的問題

【缺點】：會產生大量的日誌，尤其是 alter table 的時候會讓日誌暴漲

• MIXED

基於 STATMENT 和 ROW 兩種模式的混合複製( mixed-based replication, MBR )，一般的複製使用 STATEMENT 模式儲存 bin log ，對於 STATEMENT 模式無法複製的操作使用 ROW 模式儲存 bin log

那既然bin log也是日誌檔案，那它是在什麼記錄資料的呢？

其實 MySQL 在提交事務的時候，不僅僅會將 redo log buffer 中的資料寫入到redo log 檔案中，同時也會將本次修改的資料記錄到 bin log檔案中，同時會將本次修改的bin log檔名和修改的內容在bin log中的位置記錄到redo log中，最後還會在redo log最後寫入 commit 標記，這樣就表示本次事務被成功的提交了。

如果在資料被寫入到bin log檔案的時候，剛寫完，資料庫宕機了，資料會丟失嗎？

首先可以確定的是，只要redo log最後沒有 commit 標記，說明本次的事務一定是失敗的。但是資料是沒有丟失了，因為已經被記錄到redo log的磁碟檔案中了。在 MySQL 重啟的時候，就會將 redo log 中的資料恢復（載入）到Buffer Pool中。

好了，到目前為止，一個更新操作我們基本介紹得差不多，但是你有沒有感覺少了哪件事情還沒有做？是不是你也發現這個時候被更新記錄僅僅是在記憶體中執行的，哪怕是宕機又恢復了也僅僅是將更新後的記錄載入到Buffer Pool中，這個時候 MySQL 資料庫中的這條記錄依舊是舊值，也就是說記憶體中的資料在我們看來依舊是髒資料，那這個時候怎麼辦呢？

其實 MySQL 會有一個後臺執行緒，它會在某個時機將我們Buffer Pool中的髒資料刷到 MySQL 資料庫中，這樣就將記憶體和資料庫的資料保持統一了。

¶ 本文總結

到此，關於Buffer Pool、Redo Log Buffer 和undo log、redo log、bin log 概念以及關係就基本差不多了。

我們再回顧下

• Buffer Pool 是 MySQL 的一個非常重要的元件，因為針對資料庫的增刪改操作都是在 Buffer Pool 中完成的
• Undo log 記錄的是資料操作前的樣子
• redo log 記錄的是資料被操作後的樣子（redo log 是 Innodb 儲存引擎特有）
• bin log 記錄的是整個操作記錄（這個對於主從複製具有非常重要的意義）

從準備更新一條資料到事務的提交的流程描述

• 首先執行器根據 MySQL 的執行計劃來查詢資料，先是從快取池中查詢資料，如果沒有就會去資料庫中查詢，如果查詢到了就將其放到快取池中
• 在資料被快取到快取池的同時，會寫入 undo log 日誌檔案
• 更新的動作是在 BufferPool 中完成的，同時會將更新後的資料新增到 redo log buffer 中
• 完成以後就可以提交事務，在提交的同時會做以下三件事
  • 將redo log buffer中的資料刷入到 redo log 檔案中
  • 將本次操作記錄寫入到 bin log檔案中
  • 將 bin log 檔名字和更新內容在 bin log 中的位置記錄到redo log中，同時在 redo log 最後新增 commit 標記

至此表示整個更新事務已經完成

¶ 結束語

到此為止，系統是如何和 MySQL 資料庫打交道，提交一條更新的 SQL 語句到 MySQL，MySQL 執行了哪些流程，做了哪些事情從巨集觀上都已經講解完成了。更多的 Buffer Pool 的細節將會在之後的文章中詳解

¶ 文章來源

• 版權宣告：本文為博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結和本宣告。
• 原文連結：https://blog.csdn.net/weixin_41385912/article/details/112975752