真實的面試翻車經歷，我以為我對Mysql（ACID原理、事務隔離級別、Mysql的鎖機制、事務底層實現原理）事務很熟，直到我遇到了阿里面試官。。。

前言

感謝這位網友的分享，以下面試過程全程由第一人稱

歡迎各位大佬進群共同交流學習，我們的交流分享群：1149778920 暗號:CSDN
博主在這裡給大家整理了包括但不限於：JAVA基礎和進階類、Spring、Spring boot、Spring MVC、MyBatis、MySQL、JVM等各種資料有，免費分享給各位進群的小夥伴

閒話不多扯，我們們直接進入正題

迎面走來了一個風塵僕僕的身穿格子衫的男子，手裡拿著一個MacBook Pro，看著那稀少的髮量，和那從容淡定的眼神。

我心裡一顫，我去，這是架構師，架構師來面我技術面，我心裡頓時不淡定了，表面很穩實則心裡慌得一批。

果然，他手裡拿著我的簡歷，快速的掃了一下，然後用眼角餘光看了一下我，上來就開問。

Mysql事務簡介

面試官： 看你簡歷上說精通Mysql優化方法，你先來說說你對Mysql的事務的瞭解吧。

我心裡喜了一下，這個簡單啊，哥我可是北大(背大)的，再來面試之前，早就有準備的，二話不說，上去就是背。

我： 好的，資料庫的事務是指一組sql語句組成的資料庫邏輯處理單元，在這組的sql操作中，要麼全部執行成功，要麼全部執行失敗。

我： 這裡的一組sql操作，舉個簡單又經典的例子就是轉賬了，事務A中要進行轉賬，那麼轉出的賬號要扣錢，轉入的賬號要加錢，這兩個操作都必須同時執行成功，為了確保資料的一致性。

面試官： 剛才你提到了資料一致性，你知道事務的特性嗎？說說你的理解。

ACID簡介

我： 在Mysql中事務的四大特性主要包含：原子性（Atomicity）、一致性（Consistent）、隔離性（Isalotion）、永續性(Durable)，簡稱為ACID。

我： 原子性是指事務的原子性操作，對資料的修改要麼全部執行成功，要麼全部失敗，實現事務的原子性，是基於日誌的Redo/Undo機制。

我： 一致性是指執行事務前後的狀態要一致，可以理解為資料一致性。隔離性側重指事務之間相互隔離，不受影響，這個與事務設定的隔離級別有密切的關係。

我： 永續性則是指在一個事務提交後，這個事務的狀態會被持久化到資料庫中，也就是事務提交，對資料的新增、更新將會持久化到資料庫中。

我： 在我的理解中，原子性、隔離性、永續性都是為了保障一致性而存在的，一致性也是最終的目的。

心裡暗自歡喜，背完了，平時背的多，面試就會說，幸好難不倒我。

ACID原理

面試官： 剛才你說原子性是基於日誌的Redo/Undo機制，你能說一說Redo/Undo機制嗎？

啊哈？我都說了什麼，不小心給自己埋了一顆大雷。不慌，哥腦子裡還有貨，假裝若有所思的停了幾十秒，接著背。

我： Redo/Undo機制比較簡單，它們將所有對資料的更新操作都寫到日誌中。

我： Redo log用來記錄某資料塊被修改後的值，可以用來恢復未寫入 data file 的已成功事務更新的資料；Undo log是用來記錄資料更新前的值，保證資料更新失敗能夠回滾。

我： 假如資料庫在執行的過程中，不小心崩了，可以通過該日誌的方式，回滾之前已經執行成功的操作，實現事務的一致性。

面試官： 可以舉一個場景，說一下具體的實現流程嗎？

我： 可以的，假如某個時刻資料庫崩潰，在崩潰之前有事務A和事務B在執行，事務A已經提交，而事務B還未提交。當資料庫重啟進行 crash-recovery 時，就會通過Redo log將已經提交事務的更改寫到資料檔案，而還沒有提交的就通過Undo log進行roll back。

事務隔離級別

面試官： 之前你還提到事務的隔離級別，你能說一說嗎？

我： 可以的，在Mysql中事務的隔離級別分為四大等級，讀未提交（READ UNCOMMITTED）、讀提交 （READ COMMITTED）、可重複讀 （REPEATABLE READ）、序列化 （SERIALIZABLE）。

我： 讀未提交會讀到另一個事務的未提交的資料，產生髒讀問題，讀提交則解決了髒讀的，出現了不可重複讀，即在一個事務任意時刻讀到的資料可能不一樣，可能會受到其它事務對資料修改提交後的影響，一般是對於update的操作。

我： 可重複讀解決了之前不可重複讀和髒讀的問題，但是由帶來了幻讀的問題，幻讀一般是針對inser操作。

我： 例如：第一個事務查詢一個User表id=100發現不存在該資料行，這時第二個事務又進來了，新增了一條id=100的資料行並且提交了事務。

我： 這時第一個事務新增一條id=100的資料行會報主鍵衝突，第一個事務再select一下，發現id=100資料行已經存在，這就是幻讀。

面試官： 小夥子你能演示一下嗎？我不太會你能教教我嗎？我電腦在這裡，你演示我看一看。

男人的嘴騙人的鬼，我信你個鬼，你這糟老頭子壞得很，出來裝X總是要還的，只能默默含淚把它敲完。

我： 首先建立一個User表，最為一個測試表，測試表裡面有三個欄位，並插入兩條測試資料。

CREATE TABLE User (
  id INT(11) NOT NULL PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(20),
  age INT	DEFAULT 0
) ENGINE=InnoDB DEFAULT CHARSET=gb2312;

INSERT INTO `user` VALUES (1, 'zhangsan', 23);
INSERT INTO `user` VALUES (2, 'lisi', 20);

我： 在Mysql中可以先查詢一下他的預設隔離級別，可以看出Mysql的預設隔離級別是REPEATABLE-READ。

我： 先來演示一下讀未提交，先把預設的隔離級別修改為READ UNCOMMITTED。

我： 他設定隔離級別的語句中set global transaction isolation level read uncommitted，這裡的global也可以換成session，global表示全域性的，而session表示當前會話，也就是當前視窗有效。

我： 當設定完隔離級別後對於之前開啟的會話，是無效的，要重新開啟一個視窗設定隔離級別才生效。

我： 然後是開啟事務，Mysql中開啟事務有兩種方式begin/start transaction，最後提交事務執行commit，或者回滾事務rollback。

我： 在執行begin/start transaction命令，它們並不是一個事務的起點，在執行完它們後的第一個sql語句，才表示事務真正的啟動 。

我： 這裡直接開啟兩個新的視窗，同時開啟事務，在第一個視窗先update一個id=1的資料行name改為’非科班的科班’，執行成功。

我： 然後再第二個視窗執行兩次的查詢，分別是視窗一update之前的查詢和update之後的查詢。

我： 第一個session產生的未提交的事務的狀態就會直接影響到第二sesison，也就是髒讀。

我： 對於讀提交也是一樣的，開啟事務後，第一個事務先執行查詢資料，然後第二個session執行update操作，但是還沒有commit，這是第一個session再次select，資料並沒有改變，再第二個session執行commit之後，第一個session再次select就是改變後的資料了。

我： 這樣第一個事務的查詢結果就會收到第二事務的影響，這個也就是產生不可重複讀的問題。

面試官： 小夥子你能畫一下他執行的過程圖嗎？你講的我有點亂，我還沒有徹底明白。

我心裡一萬隻什麼馬在飛過，欲哭無淚，這面試官真難伺候，說時遲那時快，從左屁股兜抽出筆，從右屁股兜拿出紙，開始畫。

我： 這個是讀提交的時間軸圖，讀未提交的時間軸圖，原理也一樣的，第二個select的時候資料就已經改變了。

這是面試官拿過我的圖看了一點，微微的點了點頭，嘴角露出思思的笑意，我想你這糟老頭子應該不會再刁難我了吧。

面試官： 嗯，你接著演示你的可重複讀吧。

我 ： 嗯，好的，然後就是可重複讀，和之前一樣的操作。

我： 將兩個session開啟為REPEATABLE READ，同時開啟事務，在第一個事務中先select，然後在第二個事務裡面update資料行，可以發現即使第二個事務已經commit，第一個事務再次select資料也還是沒有改變，這就解決了不可重複讀的問題。

我： 這裡有個不同的地方就是在Mysql中，預設的不可重複讀個隔離級別也解決了幻讀的問題。

我： 從上面的演示中可以看出第一個事務中先select一個id=3的資料行，這條資料行是不存在的，返回Empty set，然後第二個事務中insert一條id=3的資料行並且commit，第一個事務中再次select的，資料也好是沒有id=3的資料行。

我： 最後的序列化，樣式步驟也是一樣的，結果也和Mysql中預設的個可重複讀隔離級別的結果一樣，序列化的執行流程相當於把事務的執行過程變為順序執行，我這邊就不再做演示了。

我： 這四大等級從上到下，隔離的效果是逐漸增強，但是效能卻是越來越差。

Mysql的鎖機制

面試官： 哦？效能越來越差？為什麼會效能越來越差？你能說一說原因嗎？

哎呀，我這嘴，少說一句會死啊，這下好了，這個得說底層實現原理了，從原來的假裝若有所思，變成了真正得若有所思。

我： 這個得從Mysq的鎖說起，在Mysql中的鎖可以分為分享鎖/讀鎖（Shared Locks）、排他鎖/寫鎖（Exclusive Locks） 、間隙鎖、行鎖（Record Locks）、表鎖。

我： 在四個隔離級別中加鎖肯定是要消耗效能的，而讀未提交是沒有加任何鎖的，所以對於它來說也就是沒有隔離的效果，所以它的效能也是最好的。

我： 對於序列化加的是一把大鎖，讀的時候加共享鎖，不能寫，寫的時候，加的是排它鎖，阻塞其它事務的寫入和讀取，若是其它的事務長時間不能寫入就會直接報超時，所以它的效能也是最差的，對於它來就沒有什麼併發性可言。

我： 對於讀提交和可重複讀，他們倆的實現是兼顧解決資料問題，然後又要有一定的併發行，所以在實現上鎖機制會比序列化優化很多，提高併發性，所以效能也會比較好。

事務底層實現原理

我： 他們倆的底層實現採用的是MVCC（多版本併發控制）方式進行實現。

面試官： 你能先說一下先這幾個鎖的概念嗎？我不是很懂，說說你的理解。

我： 哦，好的，共享鎖是針對同一份資料，多個讀操作可以同時進行，簡單來說即讀加鎖，不能寫並且可並行讀；排他鎖針對寫操作，假如當前寫操作沒有完成，那麼它會阻斷其它的寫鎖和讀鎖，即寫加鎖，其它讀寫都阻塞 。

我： 而行鎖和表鎖，是從鎖的粒度上進行劃分的，行鎖鎖定當前資料行，鎖的粒度小，加鎖慢，發生鎖衝突的概率小，併發度高，行鎖也是MyISAM和InnoDB的區別之一，InnoDB支援行鎖並且支援事務 。

我： 而表鎖則鎖的粒度大，加鎖快，開銷小，但是鎖衝突的概率大，併發度低。

我： 間隙鎖則分為兩種：Gap Locks和Next-Key Locks。Gap Locks會鎖住兩個索引之間的區間，比如select * from User where id>3 and id<5 for update，就會在區間（3，5）之間加上Gap Locks。

我： Next-Key Locks是Gap Locks+Record Locks形成閉區間鎖select * from User where id>=3 and id=<5 for update，就會在區間[3,5]之間加上Next-Key Locks。

面試官： 那Mysql中什麼時候會加鎖呢？

我： 在資料庫的增、刪、改、查中，只有增、刪、改才會加上排它鎖，而只是查詢並不會加鎖，只能通過在select語句後顯式加lock in share mode或者for update來加共享鎖或者排它鎖。

面試官： 你在上面提到MVCC（多版本併發控制），你能說一說原理嗎？

我： 在實現MVCC時用到了一致性檢視，用於支援讀提交和可重複讀的實現。

我： 在實現可重複讀的隔離級別，只需要在事務開始的時候建立一致性檢視，也叫做快照，之後的查詢裡都共用這個一致性檢視，後續的事務對資料的更改是對當前事務是不可見的，這樣就實現了可重複讀。

我： 而讀提交，每一個語句執行前都會重新計算出一個新的檢視，這個也是可重複讀和讀提交在MVCC實現層面上的區別。

面試官： 那你知道快照（檢視）在MVCC底層是怎麼工作的嗎？

我： 在InnoDB 中每一個事務都有一個自己的事務id，並且是唯一的，遞增的 。

我： 對於Mysql中的每一個資料行都有可能存在多個版本，在每次事務更新資料的時候，都會生成一個新的資料版本，並且把自己的資料id賦值給當前版本的row trx_id。

面試官： 小夥子你可以畫個圖我看看嗎？我不是很明白。

我有什麼辦法呢？完全沒辦法，只能又從屁股兜裡拿出筆和紙，迅速的畫了起來，要是這次面試不過就血虧啊，浪費了我兩張紙和筆水，現在的筆和紙多貴啊，只能豁出去了。

我： 如圖中所示，假如三個事務更新了同一行資料，那麼就會有對應的三個資料版本。

我： 實際上版本1、版本2並非實際物理存在的，而圖中的U1和U2實際就是undo log，這v1和v2版本是根據當前v3和undo log計算出來的。

面試官： 那對於一個快照來說，你知道它要遵循什麼規則嗎？

我： 嗯，對於一個事務檢視來說除了對自己更新的總是可見，另外還有三種情況：版本未提交的，都是不可見的；版本已經提交，但是是在建立檢視之後提交的也是不可見的；版本已經提交，若是在建立檢視之前提交的是可見的。

面試官： 假如兩個事務執行寫操作，又怎麼保證併發呢？

我： 假如事務1和事務2都要執行update操作，事務1先update資料行的時候，先回獲取行鎖，鎖定資料，當事務2要進行update操作的時候，也會取獲取該資料行的行鎖，但是已經被事務1佔有，事務2只能wait。

我： 若是事務1長時間沒有釋放鎖，事務2就會出現超時異常 。

面試官： 這個是在update的where後的條件是在有索引的情況下吧？

我： 嗯，是的 。

面試官： 那沒有索引的條件下呢？沒辦法快速定位到資料行呢？

我： 若是沒有索引的條件下，就獲取所有行，都加上行鎖，然後Mysql會再次過濾符合條件的的行並釋放鎖，只有符合條件的行才會繼續持有鎖。

我： 這樣的效能消耗也會比較大。

面試官： 嗯嗯

此時面試官看看手錶一個多鍾已經過去了，也已經到了飯點時刻，我想他應該是肚子餓了，不會繼續追問吧，兩人持續僵了三十秒，他終於開口了。

面試官： 小夥子，現在時間也已經到了飯點了，今天的面試就到此結束吧，你回去等通知吧。

我： 。。。。。。。。。。

文章結尾

博主在這裡給大家發個福利~
這裡整理了20多家公司的真實面試經歷，以及各種關於Spring、Spring boot、Spring MVC、MyBatis、MySQL、JVM等知識點，如果有需要的小夥伴可以加群1149778920 來自行領取 暗號：CSDN
以下是部分資料截圖（所有資料均已整合成文件，pdf壓縮打包處理）。