邏輯架構(gòu)和存儲引擎

自動提交

MySQL 中默認采用的是自動提交(autocommit)模式，如下所示：

在自動提交模式下，如果沒有 start transaction 顯式地開始一個事務(wù)，那么每個 sql 語句都會被當做一個事務(wù)執(zhí)行提交操作。

通過如下方式，可以關(guān)閉 autocommit;需要注意的是，autocommit 參數(shù)是針對連接的，在一個連接中修改了參數(shù)，不會對其他連接產(chǎn)生影響。

如果關(guān)閉了 autocommit，則所有的 sql 語句都在一個事務(wù)中，直到執(zhí)行了 commit 或 rollback，該事務(wù)結(jié)束，同時開始了另外一個事務(wù)。

特殊操作

在 MySQL 中，存在一些特殊的命令，如果在事務(wù)中執(zhí)行了這些命令，會馬上強制執(zhí)行 commit 提交事務(wù);如 DDL 語句(create table/drop table/alter/table)、lock tables 語句等等。

不過，常用的 select、insert、update 和 delete 命令，都不會強制提交事務(wù)。

ACID 特性

ACID 是衡量事務(wù)的四個特性：

原子性(Atomicity，或稱不可分割性)一致性(Consistency)隔離性(Isolation)持久性(Durability)按照嚴格的標準，只有同時滿足 ACID 特性才是事務(wù);但是在各大數(shù)據(jù)庫廠商的實現(xiàn)中，真正滿足 ACID 的事務(wù)少之又少。

例如 MySQL 的 NDB Cluster 事務(wù)不滿足持久性和隔離性;InnoDB 默認事務(wù)隔離級別是可重復讀，不滿足隔離性;Oracle 默認的事務(wù)隔離級別為 READ COMMITTED，不滿足隔離性……

因此與其說 ACID 是事務(wù)必須滿足的條件，不如說它們是衡量事務(wù)的四個維度。

下面將詳細介紹 ACID 特性及其實現(xiàn)原理，為了便于理解，介紹的順序不是嚴格按照 A-C-I-D。

ACID 特性及其實現(xiàn)原理

原子性

定義

原子性是指一個事務(wù)是一個不可分割的工作單位，其中的操作要么都做，要么都不做。

如果事務(wù)中一個 sql 語句執(zhí)行失敗，則已執(zhí)行的語句也必須回滾，數(shù)據(jù)庫退回到事務(wù)前的狀態(tài)。

實現(xiàn)原理：undo log

在說明原子性原理之前，首先介紹一下 MySQL 的事務(wù)日志。MySQL 的日志有很多種，如二進制日志、錯誤日志、查詢?nèi)罩?、慢查詢?nèi)罩镜取?/p>

此外 InnoDB 存儲引擎還提供了兩種事務(wù)日志：

redo log(重做日志)undo log(回滾日志)其中 redo log 用于保證事務(wù)持久性;undo log 則是事務(wù)原子性和隔離性實現(xiàn)的基礎(chǔ)。

下面說回 undo log。實現(xiàn)原子性的關(guān)鍵，是當事務(wù)回滾時能夠撤銷所有已經(jīng)成功執(zhí)行的 sql 語句。

InnoDB 實現(xiàn)回滾，靠的是 undo log：

當事務(wù)對數(shù)據(jù)庫進行修改時，InnoDB 會生成對應(yīng)的 undo log。如果事務(wù)執(zhí)行失敗或調(diào)用了 rollback，導致事務(wù)需要回滾，便可以利用 undo log 中的信息將數(shù)據(jù)回滾到修改之前的樣子。undo log 屬于邏輯日志，它記錄的是 sql 執(zhí)行相關(guān)的信息。當發(fā)生回滾時，InnoDB 會根據(jù) undo log 的內(nèi)容做與之前相反的工作：

對于每個 insert，回滾時會執(zhí)行 delete。對于每個 delete，回滾時會執(zhí)行 insert。對于每個 update，回滾時會執(zhí)行一個相反的 update，把數(shù)據(jù)改回去。以 update 操作為例：當事務(wù)執(zhí)行 update 時，其生成的 undo log 中會包含被修改行的主鍵(以便知道修改了哪些行)、修改了哪些列、這些列在修改前后的值等信息，回滾時便可以使用這些信息將數(shù)據(jù)還原到 update 之前的狀態(tài)。

持久性

定義

持久性是指事務(wù)一旦提交，它對數(shù)據(jù)庫的改變就應(yīng)該是永久性的。接下來的其他操作或故障不應(yīng)該對其有任何影響。

實現(xiàn)原理：redo log

redo log 和 undo log 都屬于 InnoDB 的事務(wù)日志。下面先聊一下 redo log 存在的背景。

InnoDB 作為 MySQL 的存儲引擎，數(shù)據(jù)是存放在磁盤中的，但如果每次讀寫數(shù)據(jù)都需要磁盤 IO，效率會很低。

為此，InnoDB 提供了緩存(Buffer Pool)，Buffer Pool 中包含了磁盤中部分數(shù)據(jù)頁的映射，作為訪問數(shù)據(jù)庫的緩沖：

當從數(shù)據(jù)庫讀取數(shù)據(jù)時，會首先從 Buffer Pool 中讀取，如果 Buffer Pool 中沒有，則從磁盤讀取后放入 Buffer Pool。當向數(shù)據(jù)庫寫入數(shù)據(jù)時，會首先寫入 Buffer Pool，Buffer Pool 中修改的數(shù)據(jù)會定期刷新到磁盤中(這一過程稱為刷臟)。Buffer Pool 的使用大大提高了讀寫數(shù)據(jù)的效率，但是也帶來了新的問題：如果 MySQL 宕機，而此時 Buffer Pool 中修改的數(shù)據(jù)還沒有刷新到磁盤，就會導致數(shù)據(jù)的丟失，事務(wù)的持久性無法保證。

于是，redo log 被引入來解決這個問題：當數(shù)據(jù)修改時，除了修改 Buffer Pool 中的數(shù)據(jù)，還會在 redo log 記錄這次操作;當事務(wù)提交時，會調(diào)用 fsync 接口對 redo log 進行刷盤。

如果 MySQL 宕機，重啟時可以讀取 redo log 中的數(shù)據(jù)，對數(shù)據(jù)庫進行恢復。

redo log 采用的是 WAL(Write-ahead logging，預寫式日志)，所有修改先寫入日志，再更新到 Buffer Pool，保證了數(shù)據(jù)不會因 MySQL 宕機而丟失，從而滿足了持久性要求。

既然 redo log 也需要在事務(wù)提交時將日志寫入磁盤，為什么它比直接將 Buffer Pool 中修改的數(shù)據(jù)寫入磁盤(即刷臟)要快呢?

主要有以下兩方面的原因：

刷臟是隨機 IO，因為每次修改的數(shù)據(jù)位置隨機，但寫 redo log 是追加操作，屬于順序 IO。刷臟是以數(shù)據(jù)頁(Page)為單位的，MySQL 默認頁大小是 16KB，一個 Page 上一個小修改都要整頁寫入;而 redo log 中只包含真正需要寫入的部分，無效 IO 大大減少。redo log 與 binlog

我們知道，在 MySQL 中還存在 binlog(二進制日志)也可以記錄寫操作并用于數(shù)據(jù)的恢復，但二者是有著根本的不同的。

• 作用不同：

redo log 是用于 crash recovery 的，保證 MySQL 宕機也不會影響持久性;

binlog 是用于 point-in-time recovery 的，保證服務(wù)器可以基于時間點恢復數(shù)據(jù)，此外 binlog 還用于主從復制。

• 層次不同：

redo log 是 InnoDB 存儲引擎實現(xiàn)的，而 binlog 是 MySQL 的服務(wù)器層(可以參考文章前面對 MySQL 邏輯架構(gòu)的介紹)實現(xiàn)的，同時支持 InnoDB 和其他存儲引擎。

• 內(nèi)容不同：

redo log 是物理日志，內(nèi)容基于磁盤的 Page。binlog 是邏輯日志，內(nèi)容是一條條 sql。

• 寫入時機不同：

redo log 的寫入時機相對多元。前面曾提到，當事務(wù)提交時會調(diào)用 fsync 對 redo log 進行刷盤;這是默認情況下的策略，修改 innodb_flush_log_at_trx_commit 參數(shù)可以改變該策略，但事務(wù)的持久性將無法保證。除了事務(wù)提交時，還有其他刷盤時機：如 master thread 每秒刷盤一次 redo log 等，這樣的好處是不一定要等到 commit 時刷盤，commit 速度大大加快。

binlog 在事務(wù)提交時寫入。

隔離性

定義

與原子性、持久性側(cè)重于研究事務(wù)本身不同，隔離性研究的是不同事務(wù)之間的相互影響。

隔離性是指事務(wù)內(nèi)部的操作與其他事務(wù)是隔離的，并發(fā)執(zhí)行的各個事務(wù)之間不能互相干擾。

嚴格的隔離性，對應(yīng)了事務(wù)隔離級別中的 Serializable(可串行化)，但實際應(yīng)用中出于性能方面的考慮很少會使用可串行化。

隔離性追求的是并發(fā)情形下事務(wù)之間互不干擾。簡單起見，我們僅考慮最簡單的讀操作和寫操作(暫時不考慮帶鎖讀等特殊操作)。

那么隔離性的探討，主要可以分為兩個方面：

(一個事務(wù))寫操作對(另一個事務(wù))寫操作的影響：鎖機制保證隔離性。(一個事務(wù))寫操作對(另一個事務(wù))讀操作的影響：MVCC 保證隔離性。鎖機制

首先來看兩個事務(wù)的寫操作之間的相互影響。隔離性要求同一時刻只能有一個事務(wù)對數(shù)據(jù)進行寫操作，InnoDB 通過鎖機制來保證這一點。

鎖機制的基本原理可以概括為：

事務(wù)在修改數(shù)據(jù)之前，需要先獲得相應(yīng)的鎖。獲得鎖之后，事務(wù)便可以修改數(shù)據(jù)。該事務(wù)操作期間，這部分數(shù)據(jù)是鎖定的，其他事務(wù)如果需要修改數(shù)據(jù)，需要等待當前事務(wù)提交或回滾后釋放鎖。行鎖與表鎖：按照粒度，鎖可以分為表鎖、行鎖以及其他位于二者之間的鎖。

表鎖在操作數(shù)據(jù)時會鎖定整張表，并發(fā)性能較差;行鎖則只鎖定需要操作的數(shù)據(jù)，并發(fā)性能好。

但是由于加鎖本身需要消耗資源(獲得鎖、檢查鎖、釋放鎖等都需要消耗資源)，因此在鎖定數(shù)據(jù)較多情況下使用表鎖可以節(jié)省大量資源。

MySQL 中不同的存儲引擎支持的鎖是不一樣的，例如 MyIsam 只支持表鎖，而 InnoDB 同時支持表鎖和行鎖，且出于性能考慮，絕大多數(shù)情況下使用的都是行鎖。

如何查看鎖信息?有多種方法可以查看 InnoDB 中鎖的情況，例如：

select * from information_schema.innodb_locks; #鎖的概況
show engine innodb status; #InnoDB整體狀態(tài)，

其中包括鎖的情況下面來看一個例子：

在事務(wù)A中執(zhí)行：start transaction;update account SET balance = 1000 where id = 1;

在事務(wù)B中執(zhí)行：start transaction;update account SET balance = 2000 where id = 1;

此時查看鎖的情況：

show engine innodb status 查看鎖相關(guān)的部分：

通過上述命令可以查看事務(wù) 24052 和 24053 占用鎖的情況;其中 lock_type 為 RECORD，代表鎖為行鎖(記錄鎖);lock_mode 為 X，代表排它鎖(寫鎖)。

除了排它鎖(寫鎖)之外，MySQL 中還有共享鎖(讀鎖)的概念。由于本文重點是 MySQL 事務(wù)的實現(xiàn)原理，因此對鎖的介紹到此為止。

介紹完寫操作之間的相互影響，下面討論寫操作對讀操作的影響。

臟讀、不可重復讀和幻讀

首先來看并發(fā)情況下，讀操作可能存在的三類問題。

①臟讀：當前事務(wù)(A)中可以讀到其他事務(wù)(B)未提交的數(shù)據(jù)(臟數(shù)據(jù))，這種現(xiàn)象是臟讀。

舉例如下(以賬戶余額表為例)：

②不可重復讀：在事務(wù) A 中先后兩次讀取同一個數(shù)據(jù)，兩次讀取的結(jié)果不一樣，這種現(xiàn)象稱為不可重復讀。

臟讀與不可重復讀的區(qū)別在于：前者讀到的是其他事務(wù)未提交的數(shù)據(jù)，后者讀到的是其他事務(wù)已提交的數(shù)據(jù)。

舉例如下：

③幻讀：在事務(wù) A 中按照某個條件先后兩次查詢數(shù)據(jù)庫，兩次查詢結(jié)果的條數(shù)不同，這種現(xiàn)象稱為幻讀。

不可重復讀與幻讀的區(qū)別可以通俗的理解為：前者是數(shù)據(jù)變了，后者是數(shù)據(jù)的行數(shù)變了。

舉例如下：

事務(wù)隔離級別

sql 標準中定義了四種隔離級別，并規(guī)定了每種隔離級別下上述幾個問題是否存在。

一般來說，隔離級別越低，系統(tǒng)開銷越低，可支持的并發(fā)越高，但隔離性也越差。

隔離級別與讀問題的關(guān)系如下：

在實際應(yīng)用中，讀未提交在并發(fā)時會導致很多問題，而性能相對于其他隔離級別提高卻很有限，因此使用較少。

可串行化強制事務(wù)串行，并發(fā)效率很低，只有當對數(shù)據(jù)一致性要求極高且可以接受沒有并發(fā)時使用，因此使用也較少。

因此在大多數(shù)數(shù)據(jù)庫系統(tǒng)中，默認的隔離級別是讀已提交(如 Oracle)或可重復讀(后文簡稱 RR)。

可以通過如下兩個命令分別查看全局隔離級別和本次會話的隔離級別：

InnoDB 默認的隔離級別是 RR，后文會重點介紹 RR。需要注意的是，在 SQL 標準中，RR 是無法避免幻讀問題的，但是 InnoDB 實現(xiàn)的 RR 避免了幻讀問題。

MVCC

RR 解決臟讀、不可重復讀、幻讀等問題，使用的是 MVCC：MVCC 全稱 Multi-Version Concurrency Control，即多版本的并發(fā)控制協(xié)議。

下面的例子很好的體現(xiàn)了 MVCC 的特點：在同一時刻，不同的事務(wù)讀取到的數(shù)據(jù)可能是不同的(即多版本)——在 T5 時刻，事務(wù) A 和事務(wù) C 可以讀取到不同版本的數(shù)據(jù)。

MVCC 最大的優(yōu)點是讀不加鎖，因此讀寫不沖突，并發(fā)性能好。InnoDB 實現(xiàn) MVCC，多個版本的數(shù)據(jù)可以共存，主要是依靠數(shù)據(jù)的隱藏列(也可以稱之為標記位)和 undo log。

其中數(shù)據(jù)的隱藏列包括了該行數(shù)據(jù)的版本號、刪除時間、指向 undo log 的指針等等。

當讀取數(shù)據(jù)時，MySQL 可以通過隱藏列判斷是否需要回滾并找到回滾需要的 undo log，從而實現(xiàn) MVCC;隱藏列的詳細格式不再展開。

下面結(jié)合前文提到的幾個問題分別說明。

①臟讀

當事務(wù) A 在 T3 時間節(jié)點讀取 zhangsan 的余額時，會發(fā)現(xiàn)數(shù)據(jù)已被其他事務(wù)修改，且狀態(tài)為未提交。

此時事務(wù) A 讀取最新數(shù)據(jù)后，根據(jù)數(shù)據(jù)的 undo log 執(zhí)行回滾操作，得到事務(wù) B 修改前的數(shù)據(jù)，從而避免了臟讀。

②不可重復讀

當事務(wù) A 在 T2 節(jié)點第一次讀取數(shù)據(jù)時，會記錄該數(shù)據(jù)的版本號(數(shù)據(jù)的版本號是以 row 為單位記錄的)，假設(shè)版本號為 1;當事務(wù) B 提交時，該行記錄的版本號增加，假設(shè)版本號為 2。

當事務(wù) A 在 T5 再一次讀取數(shù)據(jù)時，發(fā)現(xiàn)數(shù)據(jù)的版本號(2)大于第一次讀取時記錄的版本號(1)，因此會根據(jù) undo log 執(zhí)行回滾操作，得到版本號為 1 時的數(shù)據(jù)，從而實現(xiàn)了可重復讀。

③幻讀

InnoDB 實現(xiàn)的 RR 通過 next-keylock 機制避免了幻讀現(xiàn)象。

next-keylock 是行鎖的一種，實現(xiàn)相當于 record lock(記錄鎖) + gap lock(間隙鎖);其特點是不僅會鎖住記錄本身(record lock 的功能)，還會鎖定一個范圍(gap lock 的功能)。

當然，這里我們討論的是不加鎖讀：此時的 next-key lock 并不是真的加鎖，只是為讀取的數(shù)據(jù)增加了標記(標記內(nèi)容包括數(shù)據(jù)的版本號等);準確起見姑且稱之為類 next-key lock 機制。

還是以前面的例子來說明：

當事務(wù) A 在 T2 節(jié)點第一次讀取 0

這樣當 T5 時刻再次讀取 0

小結(jié)：概括來說，InnoDB 實現(xiàn)的 RR，通過鎖機制、數(shù)據(jù)的隱藏列、undo log 和類 next-key lock，實現(xiàn)了一定程度的隔離性，可以滿足大多數(shù)場景的需要。

不過需要說明的是，RR 雖然避免了幻讀問題，但是畢竟不是 Serializable，不能保證完全的隔離。

下面是一個例子，大家可以自己驗證一下：

一致性

基本概念

一致性是指事務(wù)執(zhí)行結(jié)束后，數(shù)據(jù)庫的完整性約束沒有被破壞，事務(wù)執(zhí)行的前后都是合法的數(shù)據(jù)狀態(tài)。

數(shù)據(jù)庫的完整性約束包括但不限于：

實體完整性(如行的主鍵存在且唯一)列完整性(如字段的類型、大小、長度要符合要求)外鍵約束用戶自定義完整性(如轉(zhuǎn)賬前后，兩個賬戶余額的和應(yīng)該不變)實現(xiàn)

可以說，一致性是事務(wù)追求的最終目標：前面提到的原子性、持久性和隔離性，都是為了保證數(shù)據(jù)庫狀態(tài)的一致性。此外，除了數(shù)據(jù)庫層面的保障，一致性的實現(xiàn)也需要應(yīng)用層面進行保障。

實現(xiàn)一致性的措施包括：

保證原子性、持久性和隔離性，如果這些特性無法保證，事務(wù)的一致性也無法保證。數(shù)據(jù)庫本身提供保障，例如不允許向整形列插入字符串值、字符串長度不能超過列的限制等。應(yīng)用層面進行保障，例如如果轉(zhuǎn)賬操作只扣除轉(zhuǎn)賬者的余額，而沒有增加接收者的余額，無論數(shù)據(jù)庫實現(xiàn)的多么完美，也無法保證狀態(tài)的一致。總結(jié)

下面總結(jié)一下 ACID 特性及其實現(xiàn)原理：

原子性：語句要么全執(zhí)行，要么全不執(zhí)行，是事務(wù)最核心的特性。

事務(wù)本身就是以原子性來定義的;實現(xiàn)主要基于 undo log。

持久性：保證事務(wù)提交后不會因為宕機等原因?qū)е聰?shù)據(jù)丟失;實現(xiàn)主要基于 redo log。

隔離性：保證事務(wù)執(zhí)行盡可能不受其他事務(wù)影響;

InnoDB 默認的隔離級別是 RR，RR 的實現(xiàn)主要基于鎖機制、數(shù)據(jù)的隱藏列、undo log 和類 next-key lock 機制。

一致性：事務(wù)追求的最終目標，一致性的實現(xiàn)既需要數(shù)據(jù)庫層面的保障，也需要應(yīng)用層面的保障。

以上就是MySql事務(wù)及ACID實現(xiàn)原理詳解的詳細內(nèi)容，更多關(guān)于MySql事務(wù)ACID原理的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論