MySQL 事務常見面試題總結 | JavaGuide 審覈中

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

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

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

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

何謂事務？

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

數據庫中途突然因爲某些原因掛掉了。
客戶端突然因爲網絡原因連接不上數據庫了。
併發訪問數據庫時，多個線程同時寫入數據庫，覆蓋了彼此的更改。
......

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

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

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

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

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

何謂數據庫事務？

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

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

那數據庫事務有什麼作用呢？

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

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

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

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

🌈 這裏要額外補充一點：只有保證了事務的持久性、原子性、隔離性之後，一致性才能得到保障。也就是說 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 開源，地址：https://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 事務隔離級別詳解。

MySQL 事務常見面試題總結 | JavaGuide 審覈中

何謂事務？

何謂數據庫事務？

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

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

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

MySQL 的默認隔離級別是什麼?

更多 MySQL 面試題

面試官：爲什麼忘記密碼要重置而不是告訴你原密碼？

京東後端實習一面（附詳解），秒掛！

Redis 八種常用數據類型詳解

OPPO 後端面試涼經（附詳細參考答案）

焦慮秋招選手，成功拿到了美團、百度、阿里等大廠offer!

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結