MySQL 事務常見面試題總結 | JavaGuide 稽核中

語言: CN / TW / HK

時間 2022-05-23 16:07:00 部落格園精華區

主題: MySQL

《Java 面試指北》來啦！這是一份教你如何更高效地準備面試的小冊，涵蓋常見八股文（系統設計、常見框架、分散式、高併發 ......）、優質面經等內容。

本文原發於 MySQL知識點&面試題總結。

你好，我是 Guide。分享一道群友面試蝦皮遇到的 MySQL 事務相關的面試真題。

這篇文章我除了會對群友面試遇到的面試真題進行了解答，還會順帶總結一下 MySQL 事務部分其他比較常見的問題，希望對你有幫助。

下面是最近更新的一些面試真題：

何謂事務？

我們設想一個場景，這個場景中我們需要插入多條相關聯的資料到資料庫，不幸的是，這個過程可能會遇到下面這些問題：

資料庫中途突然因為某些原因掛掉了。
客戶端突然因為網路原因連線不上資料庫了。
併發訪問資料庫時，多個執行緒同時寫入資料庫，覆蓋了彼此的更改。
......

上面的任何一個問題都可能會導致資料的不一致性。為了保證資料的一致性，系統必須能夠處理這些問題。事務就是我們抽象出來簡化這些問題的首選機制。事務的概念起源於資料庫，目前，已經成為一個比較廣泛的概念。

何為事務？一言蔽之， 事務是邏輯上的一組操作，要麼都執行，要麼都不執行。

事務最經典也經常被拿出來說例子就是轉賬了。假如小明要給小紅轉賬 1000 元，這個轉賬會涉及到兩個關鍵操作，這兩個操作必須都成功或者都失敗。

將小明的餘額減少 1000 元
將小紅的餘額增加 1000 元。

事務會把這兩個操作就可以看成邏輯上的一個整體，這個整體包含的操作要麼都成功，要麼都要失敗。這樣就不會出現小明餘額減少而小紅的餘額卻並沒有增加的情況。

何謂資料庫事務？

大多數情況下，我們在談論事務的時候，如果沒有特指 分散式事務 ，往往指的就是 資料庫事務 。

資料庫事務在我們日常開發中接觸的最多了。如果你的專案屬於單體架構的話，你接觸到的往往就是資料庫事務了。

那資料庫事務有什麼作用呢？

簡單來說，資料庫事務可以保證多個對資料庫的操作（也就是 SQL 語句）構成一個邏輯上的整體。構成這個邏輯上的整體的這些資料庫操作遵循： 要麼全部執行成功,要麼全部不執行 。

# 開啟一個事務
START TRANSACTION;
# 多條 SQL 語句
SQL1,SQL2...
## 提交事務
COMMIT;

另外，關係型資料庫（例如： MySQL 、 SQL Server 、 Oracle 等）事務都有 ACID 特性：

原子性 （ Atomicity ）：事務是最小的執行單位，不允許分割。事務的原子性確保動作要麼全部完成，要麼完全不起作用；
一致性 （ Consistency ）：執行事務前後，資料保持一致，例如轉賬業務中，無論事務是否成功，轉賬者和收款人的總額應該是不變的；
隔離性 （ Isolation ）：併發訪問資料庫時，一個使用者的事務不被其他事務所幹擾，各併發事務之間資料庫是獨立的；
永續性 （ Durabilily ）：一個事務被提交之後。它對資料庫中資料的改變是持久的，即使資料庫發生故障也不應該對其有任何影響。

:rainbow: 這裡要額外補充一點：只有保證了事務的永續性、原子性、隔離性之後，一致性才能得到保障。也就是說 A、I、D 是手段，C 是目的！想必大家也和我一樣，被 ACID 這個概念被誤導了很久! 我也是看周志明老師的公開課《周志明的軟體架構課》才搞清楚的（多看好書！！！）。

另外，DDIA 也就是《Designing Data-Intensive Application（資料密集型應用系統設計）》的作者在他的這本書中如是說：

Atomicity, isolation, and durability are properties of the database, whereas consis‐

tency (in the ACID sense) is a property of the application. The application may rely

on the database’s atomicity and isolation properties in order to achieve consistency,

but it’s not up to the database alone.

翻譯過來的意思是：原子性，隔離性和永續性是資料庫的屬性，而一致性（在 ACID 意義上）是應用程式的屬性。應用可能依賴資料庫的原子性和隔離屬性來實現一致性，但這並不僅取決於資料庫。因此，字母 C 不屬於 ACID 。

《Designing Data-Intensive Application（資料密集型應用系統設計）》這本書強推一波，值得讀很多遍！豆瓣有接近 90% 的人看了這本書之後給了五星好評。另外，中文翻譯版本已經在 Github 開源，地址： http://github.com/Vonng/ddia 。

併發事務帶來了哪些問題?

在典型的應用程式中，多個事務併發執行，經常會操作相同的資料來完成各自的任務（多個使用者對同一資料進行操作）。併發雖然是必須的，但可能會導致以下的問題。

髒讀（Dirty read）: 當一個事務正在訪問資料並且對資料進行了修改，而這種修改還沒有提交到資料庫中，這時另外一個事務也訪問了這個資料，然後使用了這個資料。因為這個資料是還沒有提交的資料，那麼另外一個事務讀到的這個資料是“髒資料”，依據“髒資料”所做的操作可能是不正確的。
丟失修改（Lost to modify）: 指在一個事務讀取一個數據時，另外一個事務也訪問了該資料，那麼在第一個事務中修改了這個資料後，第二個事務也修改了這個資料。這樣第一個事務內的修改結果就被丟失，因此稱為丟失修改。例如：事務 1 讀取某表中的資料 A=20，事務 2 也讀取 A=20，事務 1 修改 A=A-1，事務 2 也修改 A=A-1，最終結果 A=19，事務 1 的修改被丟失。
不可重複讀（Unrepeatable read）: 指在一個事務內多次讀同一資料。在這個事務還沒有結束時，另一個事務也訪問該資料。那麼，在第一個事務中的兩次讀資料之間，由於第二個事務的修改導致第一個事務兩次讀取的資料可能不太一樣。這就發生了在一個事務內兩次讀到的資料是不一樣的情況，因此稱為不可重複讀。
幻讀（Phantom read）: 幻讀與不可重複讀類似。它發生在一個事務（T1）讀取了幾行資料，接著另一個併發事務（T2）插入了一些資料時。在隨後的查詢中，第一個事務（T1）就會發現多了一些原本不存在的記錄，就好像發生了幻覺一樣，所以稱為幻讀。

不可重複讀和幻讀區別：不可重複讀的重點是修改比如多次讀取一條記錄發現其中某些列的值被修改，幻讀的重點在於新增或者刪除比如多次查詢同一條查詢語句（DQL）時，記錄發現記錄增多或減少了。

SQL 標準定義了哪些事務隔離級別?

SQL 標準定義了四個隔離級別：

READ-UNCOMMITTED(讀取未提交) ：最低的隔離級別，允許讀取尚未提交的資料變更，可能會導致髒讀、幻讀或不可重複讀。
READ-COMMITTED(讀取已提交) ：允許讀取併發事務已經提交的資料，可以阻止髒讀，但是幻讀或不可重複讀仍有可能發生。
REPEATABLE-READ(可重複讀) ：對同一欄位的多次讀取結果都是一致的，除非資料是被本身事務自己所修改，可以阻止髒讀和不可重複讀，但幻讀仍有可能發生。
SERIALIZABLE(可序列化) ：最高的隔離級別，完全服從 ACID 的隔離級別。所有的事務依次逐個執行，這樣事務之間就完全不可能產生干擾，也就是說，該級別可以防止髒讀、不可重複讀以及幻讀。

隔離級別	髒讀	不可重複讀	幻讀
READ-UNCOMMITTED	√	√	√
READ-COMMITTED	×	√	√
REPEATABLE-READ	×	×	√
SERIALIZABLE	×	×	×

MySQL 的隔離級別是基於鎖實現的嗎？

MySQL 的隔離級別基於鎖和 MVCC 機制共同實現的。

SERIALIZABLE 隔離級別，是通過鎖來實現的。除了 SERIALIZABLE 隔離級別，其他的隔離級別都是基於 MVCC 實現。

不過， SERIALIZABLE 之外的其他隔離級別可能也需要用到鎖機制，就比如 REPEATABLE-READ 在當前讀情況下需要使用加鎖讀來保證不會出現幻讀。

MySQL 的預設隔離級別是什麼?

MySQL InnoDB 儲存引擎的預設支援的隔離級別是 REPEATABLE-READ（可重讀） 。我們可以通過 SELECT @@tx_isolation; 命令來檢視，MySQL 8.0 該命令改為 SELECT @@transaction_isolation;

mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+

從上面對 SQL 標準定義了四個隔離級別的介紹可以看出，標準的 SQL 隔離級別定義裡，REPEATABLE-READ(可重複讀)是不可以防止幻讀的。

但是！InnoDB 實現的 REPEATABLE-READ 隔離級別其實是可以解決幻讀問題發生的，主要有下面兩種情況：

快照讀 ：由 MVCC 機制來保證不出現幻讀。
當前讀 ：使用 Next-Key Lock 進行加鎖來保證不出現幻讀，Next-Key Lock 是行鎖（Record Lock）和間隙鎖（Gap Lock）的結合，行鎖只能鎖住已經存在的行，為了避免插入新行，需要依賴間隙鎖。

因為隔離級別越低，事務請求的鎖越少，所以大部分資料庫系統的隔離級別都是 READ-COMMITTED ，但是你要知道的是 InnoDB 儲存引擎預設使用 REPEATABLE-READ 並不會有任何效能損失。

InnoDB 儲存引擎在分散式事務的情況下一般會用到 SERIALIZABLE 隔離級別。

《MySQL 技術內幕：InnoDB 儲存引擎(第 2 版)》7.7 章這樣寫到：

InnoDB 儲存引擎提供了對 XA 事務的支援，並通過 XA 事務來支援分散式事務的實現。分散式事務指的是允許多個獨立的事務資源（transactional resources）參與到一個全域性的事務中。事務資源通常是關係型資料庫系統，但也可以是其他型別的資源。全域性事務要求在其中的所有參與的事務要麼都提交，要麼都回滾，這對於事務原有的 ACID 要求又有了提高。另外，在使用分散式事務時，InnoDB 儲存引擎的事務隔離級別必須設定為 SERIALIZABLE。

關於 MySQL 事務隔離級別的詳細介紹，可以看看我寫的這篇文章： MySQL 事務隔離級別詳解。