[[376678]]

本文轉(zhuǎn)載自微信公眾號「JAVA日知錄」，作者單一色調(diào)。轉(zhuǎn)載本文請聯(lián)系JAVA日知錄公眾號。   

 小張：面試官，你好。我是來參加面試的。

面試官：你好，小張。我看了你的簡歷，精通MySQL數(shù)據(jù)庫。那你肯定知道事務(wù)吧，你能說說 事務(wù)有哪些特性 嗎?

小張：一個事務(wù)有4個特性，即ACID。

• 原子性(Atomicity)： 事務(wù)開始后的所有操作，要么全部成功要么全部失敗。
• 一致性(Consistency)： 事務(wù)開始前后數(shù)據(jù)庫的完整性約束沒有被破壞，比如：A向B轉(zhuǎn)錢，不可能出現(xiàn)A扣了錢，B沒收到錢。
• 隔離性(Isolation)：多個事務(wù)并發(fā)訪問時，事務(wù)之間是隔離的。
• 持久性(Durability)：事務(wù)完成后，事務(wù)對數(shù)據(jù)庫的操作被保存在了數(shù)據(jù)庫，不能回滾。

面試官：嗯，答的很對。那你說說事務(wù)有哪幾種隔離級別呢?

小張：事務(wù)隔離級別從高到低有四種隔離級別，分別是：串行化(SERIALIZABLE) 、可重復(fù)讀(REPEATABLE READ)、讀提交(READ COMMITTED)、讀未提交(READ UNCOMMITTED)。

面試官：嗯嗯，那你能說說這四種隔離級別分別會造成什么問題嗎?

(小張竊喜，我就知道你要這么問，還好我平時關(guān)注了 ‘ JAVA日知錄 ’ 的公眾號)

小張：好的，面試官。

如果數(shù)據(jù)庫采用 讀未提交(READ UNCOMMITTED)這種隔離級別，會造成 臟讀。事務(wù)還沒提交別人就能看到，這樣就不能保證你讀取到的數(shù)據(jù)是最終的數(shù)據(jù)，萬一別人把事務(wù)回滾了，那就出現(xiàn)了臟數(shù)據(jù)問題。

讀提交(READ COMMITTED)是指一個事務(wù)只能讀取到其他事務(wù)已經(jīng)提交了的數(shù)據(jù)，這樣就不會出現(xiàn)臟讀的問題，但是它會帶來」不可重復(fù)讀 的問題。比如 A事務(wù) 將一個人的姓名從張三改成李四，B事務(wù)在A事務(wù)提交之前讀取到的是張三，但是在A事務(wù)提交之后就變成了李四。

可重復(fù)讀(REPEATABLE READ)：可重復(fù)讀是為了解決READ COMMITTED帶來的不可重復(fù)讀問題，指的是事務(wù)不會讀取到其他事務(wù)對已有數(shù)據(jù)的修改，即使數(shù)據(jù)已經(jīng)提交了。也就是說事務(wù)開始讀取到的是什么，在事務(wù)提交之前的任意時刻，這些數(shù)據(jù)都一樣。雖然解決了不可重復(fù)讀問題，但是他又會帶來 幻讀 的問題。比如A事務(wù)將張三修改成李四，B事務(wù)再插入一個名叫李四的用戶，此時事務(wù)A再查找名叫李四的用戶會發(fā)現(xiàn)多了一條，出現(xiàn)了2個李四，這就是幻讀。

串行化(SERIALIZABLE)：解決了上面出現(xiàn)的所有問題，但是它效率最差，它將事務(wù)的執(zhí)行變成順序執(zhí)行了。

面試官：回答的不錯，那你知道 MySQL的默認(rèn)隔離級別是什么嗎?

小張：Mysql默認(rèn)的隔離級別是REPEATABLE READ，Oracle則采用的是READ COMMITTED。

面試官：但是我們使用MySQL的時候并沒有出現(xiàn)幻讀啊，怎么解決的?

小張擦了擦汗，開始有點(diǎn)緊張了：額，InnoDB主要是利用鎖來解決幻讀問題的。

面試官：對，是采用了鎖，那么具體怎么實(shí)現(xiàn)的呢?

小張：我...我突然有點(diǎn)事，我先回去了。

面試官：要了解InnoDB怎么解決幻讀得先知道InnoDB有哪幾種鎖。

• Record Lock：單個行記錄上的鎖
• Gap Lock：間隙鎖，鎖定一個范圍，而非記錄本身，遵循左開右閉原則
• Next-Key Lock：結(jié)合Gap Lock和Record Lock，鎖定一個范圍，并且鎖定記錄本身。主要解決的問題是REPEATABLE READ隔離級別下的幻讀。

注意，如果走唯一索引，那么Next-Key Lock會降級為Record Lock，即僅鎖住索引本身，而不是范圍。也就是說Next-Key Lock前置條件為事務(wù)隔離級別為RR且查詢的索引走的非唯一索引、主鍵索引。

下面我們通過具體的例子來模擬上面出現(xiàn)的幻讀問題：

CREATE TABLE T (id int ,name varchar(50),f_id int,PRIMARY KEY (id), KEY(f_id)) ENGINE=InnoDB DEFAULT CHARSET=utf8 
insert into T SELECT 1,'張三',10; 
insert into T SELECT 2,'李四',30; 

InnoDB在數(shù)據(jù)庫中會為索引維護(hù)一套B+樹，用來快速定位行記錄。B+索引樹是有序的，所以會把這張表的索引分割成幾個區(qū)間。

事務(wù)A執(zhí)行如下語句，需要將張三修改成李四。

select * from t; 
update t set name = '李四' where f_id = 10; 

這時SQL語句走非唯一索引，因此使用Next-Key Lock加鎖，不僅會給f_10=10的行加上行鎖，而且還會給這條記錄的兩邊添加上間隙鎖，即(-∞,10]、(10,30]這2個區(qū)間都加了間隙鎖。

此時如果B事務(wù)要執(zhí)行如下語句，都會報錯[Err] 1205 - Lock wait timeout exceeded; try restarting transaction

INSERT INTO T SELECT 3,'王五'，10;  -- 滿足行鎖，執(zhí)行阻塞 
INSERT INTO T SELECT 4,'趙六'，8;   -- 滿足間隙鎖，執(zhí)行阻塞 
INSERT INTO T SELECT 5,'孫七'，18;  -- 滿足間隙鎖，執(zhí)行阻塞 

不僅插入 f_id = 10 的記錄需要等待事務(wù)A提交，f_id <10、10< f_id <30 的記錄也無法完成，而大于等于30的記錄則不受影響，這足以解決幻讀問題了。

剛剛講的是f_id 是索引列的情況，那么如果 f_id不是索引列會怎么樣呢?

這時候數(shù)據(jù)庫會為整個表加上間隙鎖。所以，如果是沒有索引的話，不管 f_id 是否大于等于30，都要等待事務(wù)A提交才可以成功插入。

面試官：好了，各位看官朋友們，事務(wù)的隔離級別這個面試點(diǎn)你們清楚了嗎?希望你們的面試不會被這個問題難倒喲~

小張：學(xué)到了學(xué)到了，我下次再來。(趕緊回去把簡歷上的精通數(shù)據(jù)庫給刪掉。)