何謂事務(wù)？
我們設(shè)想一個場景，這個場景中我們需要插入多條相關(guān)聯(lián)的數(shù)據(jù)到數(shù)據(jù)庫，不幸的是，這個過程可能會遇到下面這些問題：
- 數(shù)據(jù)庫中途突然因?yàn)槟承┰驋斓袅恕?/li>
- 客戶端突然因?yàn)榫W(wǎng)絡(luò)原因連接不上數(shù)據(jù)庫了。
- 并發(fā)訪問數(shù)據(jù)庫時，多個線程同時寫入數(shù)據(jù)庫，覆蓋了彼此的更改。
- ……
上面的任何一個問題都可能會導(dǎo)致數(shù)據(jù)的不一致性。為了保證數(shù)據(jù)的一致性，系統(tǒng)必須能夠處理這些問題。事務(wù)就是我們抽象出來簡化這些問題的首選機(jī)制。事務(wù)的概念起源于數(shù)據(jù)庫，目前，已經(jīng)成為一個比較廣泛的概念。
何為事務(wù)？ 一言蔽之，事務(wù)是邏輯上的一組操作，要么都執(zhí)行，要么都不執(zhí)行。
事務(wù)最經(jīng)典也經(jīng)常被拿出來說例子就是轉(zhuǎn)賬了。假如小明要給小紅轉(zhuǎn)賬 1000 元，這個轉(zhuǎn)賬會涉及到兩個關(guān)鍵操作，這兩個操作必須都成功或者都失敗。
事務(wù)會把這兩個操作就可以看成邏輯上的一個整體，這個整體包含的操作要么都成功，要么都要失敗。這樣就不會出現(xiàn)小明余額減少而小紅的余額卻并沒有增加的情況。
何謂數(shù)據(jù)庫事務(wù)？
大多數(shù)情況下，我們在談?wù)撌聞?wù)的時候，如果沒有特指分布式事務(wù)，往往指的就是數(shù)據(jù)庫事務(wù)。
數(shù)據(jù)庫事務(wù)在我們?nèi)粘ｉ_發(fā)中接觸的最多了。如果你的項(xiàng)目屬于單體架構(gòu)的話，你接觸到的往往就是數(shù)據(jù)庫事務(wù)了。
那數(shù)據(jù)庫事務(wù)有什么作用呢？
簡單來說，數(shù)據(jù)庫事務(wù)可以保證多個對數(shù)據(jù)庫的操作（也就是 SQL 語句）構(gòu)成一個邏輯上的整體。構(gòu)成這個邏輯上的整體的這些數(shù)據(jù)庫操作遵循：要么全部執(zhí)行成功,要么全部不執(zhí)行 。
# 開啟一個事務(wù)START TRANSACTION;# 多條 SQL 語句SQL1,SQL2…## 提交事務(wù)COMMIT;
另外，關(guān)系型數(shù)據(jù)庫（例如：MySQL、SQL Server、Oracle 等）事務(wù)都有 ACID 特性：
ACID
這里要額外補(bǔ)充一點(diǎn)：只有保證了事務(wù)的持久性、原子性、隔離性之后，一致性才能得到保障。也就是說 A、I、D 是手段，C 是目的！
并發(fā)事務(wù)帶來了哪些問題?
在典型的應(yīng)用程序中，多個事務(wù)并發(fā)運(yùn)行，經(jīng)常會操作相同的數(shù)據(jù)來完成各自的任務(wù)（多個用戶對同一數(shù)據(jù)進(jìn)行操作）。并發(fā)雖然是必須的，但可能會導(dǎo)致以下的問題。
- 臟讀（Dirty read）: 當(dāng)一個事務(wù)正在訪問數(shù)據(jù)并且對數(shù)據(jù)進(jìn)行了修改，而這種修改還沒有提交到數(shù)據(jù)庫中，這時另外一個事務(wù)也訪問了這個數(shù)據(jù)，然后使用了這個數(shù)據(jù)。因?yàn)檫@個數(shù)據(jù)是還沒有提交的數(shù)據(jù)，那么另外一個事務(wù)讀到的這個數(shù)據(jù)是“臟數(shù)據(jù)”，依據(jù)“臟數(shù)據(jù)”所做的操作可能是不正確的。
- 丟失修改（Lost to modify）: 指在一個事務(wù)讀取一個數(shù)據(jù)時，另外一個事務(wù)也訪問了該數(shù)據(jù)，那么在第一個事務(wù)中修改了這個數(shù)據(jù)后，第二個事務(wù)也修改了這個數(shù)據(jù)。這樣第一個事務(wù)內(nèi)的修改結(jié)果就被丟失，因此稱為丟失修改。例如：事務(wù) 1 讀取某表中的數(shù)據(jù) A=20，事務(wù) 2 也讀取 A=20，事務(wù) 1 修改 A=A-1，事務(wù) 2 也修改 A=A-1，最終結(jié)果 A=19，事務(wù) 1 的修改被丟失。
- 不可重復(fù)讀（Unrepeatable read）: 指在一個事務(wù)內(nèi)多次讀同一數(shù)據(jù)。在這個事務(wù)還沒有結(jié)束時，另一個事務(wù)也訪問該數(shù)據(jù)。那么，在第一個事務(wù)中的兩次讀數(shù)據(jù)之間，由于第二個事務(wù)的修改導(dǎo)致第一個事務(wù)兩次讀取的數(shù)據(jù)可能不太一樣。這就發(fā)生了在一個事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的情況，因此稱為不可重復(fù)讀。
- 幻讀（Phantom read）: 幻讀與不可重復(fù)讀類似。它發(fā)生在一個事務(wù)（T1）讀取了幾行數(shù)據(jù)，接著另一個并發(fā)事務(wù)（T2）插入了一些數(shù)據(jù)時。在隨后的查詢中，第一個事務(wù)（T1）就會發(fā)現(xiàn)多了一些原本不存在的記錄，就好像發(fā)生了幻覺一樣，所以稱為幻讀。
不可重復(fù)讀和幻讀區(qū)別 ：不可重復(fù)讀的重點(diǎn)是修改比如多次讀取一條記錄發(fā)現(xiàn)其中某些列的值被修改，幻讀的重點(diǎn)在于新增或者刪除比如多次查詢同一條查詢語句（DQL）時，記錄發(fā)現(xiàn)記錄增多或減少了。
SQL 標(biāo)準(zhǔn)定義了哪些事務(wù)隔離級別?
SQL 標(biāo)準(zhǔn)定義了四個隔離級別：
- READ-UNCOMMITTED(讀取未提交) ：最低的隔離級別，允許讀取尚未提交的數(shù)據(jù)變更，可能會導(dǎo)致臟讀、幻讀或不可重復(fù)讀。
- READ-COMMITTED(讀取已提交) ：允許讀取并發(fā)事務(wù)已經(jīng)提交的數(shù)據(jù)，可以阻止臟讀，但是幻讀或不可重復(fù)讀仍有可能發(fā)生。
- REPEATABLE-READ(可重復(fù)讀) ：對同一字段的多次讀取結(jié)果都是一致的，除非數(shù)據(jù)是被本身事務(wù)自己所修改，可以阻止臟讀和不可重復(fù)讀，但幻讀仍有可能發(fā)生。
- SERIALIZABLE(可串行化) ：最高的隔離級別，完全服從 ACID 的隔離級別。所有的事務(wù)依次逐個執(zhí)行，這樣事務(wù)之間就完全不可能產(chǎn)生干擾，也就是說，該級別可以防止臟讀、不可重復(fù)讀以及幻讀。
隔離級別臟讀不可重復(fù)讀幻讀READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE
MySQL 的隔離級別是基于鎖實(shí)現(xiàn)的嗎？
MySQL 的隔離級別基于鎖和 MVCC 機(jī)制共同實(shí)現(xiàn)的。
SERIALIZABLE 隔離級別，是通過鎖來實(shí)現(xiàn)的。除了 SERIALIZABLE 隔離級別，其他的隔離級別都是基于 MVCC 實(shí)現(xiàn)。
不過， SERIALIZABLE 之外的其他隔離級別可能也需要用到鎖機(jī)制，就比如 REPEATABLE-READ 在當(dāng)前讀情況下需要使用加鎖讀來保證不會出現(xiàn)幻讀。
MySQL 的默認(rèn)隔離級別是什么?
MySQL InnoDB 存儲引擎的默認(rèn)支持的隔離級別是 REPEATABLE-READ（可重讀）。我們可以通過SELECT @@tx_isolation;命令來查看，MySQL 8.0 該命令改為SELECT @@transaction_isolation;
mysql> SELECT @@tx_isolation;+—————–+| @@tx_isolation |+—————–+| REPEATABLE-READ |+—————–+
從上面對 SQL 標(biāo)準(zhǔn)定義了四個隔離級別的介紹可以看出，標(biāo)準(zhǔn)的 SQL 隔離級別定義里，REPEATABLE-READ(可重復(fù)讀)是不可以防止幻讀的。
但是！InnoDB 實(shí)現(xiàn)的 REPEATABLE-READ 隔離級別其實(shí)是可以解決幻讀問題發(fā)生的，主要有下面兩種情況：
- 快照讀 ：由 MVCC 機(jī)制來保證不出現(xiàn)幻讀。
- 當(dāng)前讀 ：使用 Next-Key Lock 進(jìn)行加鎖來保證不出現(xiàn)幻讀，Next-Key Lock 是行鎖（Record Lock）和間隙鎖（Gap Lock）的結(jié)合，行鎖只能鎖住已經(jīng)存在的行，為了避免插入新行，需要依賴間隙鎖。
因?yàn)楦綦x級別越低，事務(wù)請求的鎖越少，所以大部分?jǐn)?shù)據(jù)庫系統(tǒng)的隔離級別都是 READ-COMMITTED ，但是你要知道的是 InnoDB 存儲引擎默認(rèn)使用 REPEATABLE-READ 并不會有任何性能損失。
InnoDB 存儲引擎在分布式事務(wù)的情況下一般會用到 SERIALIZABLE 隔離級別。
