[[442041]]

在上篇文章中涉及到了一個小小的問題，就是數(shù)據(jù)庫事務(wù)的一致性視圖是啥時候建立的?

這個問題還比較重要，如果沒搞清楚，可能會影響我們做實驗的結(jié)果，進而得出錯誤的結(jié)論，所以今天松哥和大家簡單聊一聊這個話題。

1. 錯誤演示

先給大家來一個錯誤演示。

我們打開兩個會話窗口，默認(rèn)情況下隔離級別是可重復(fù)讀，我們來看下：

首先在 A 會話中查看當(dāng)前 user 表，查看完成后開啟事務(wù)：

可以看到當(dāng)前 age 是 101。

接下來在 B 會話中修改 age：

可以看到，B 會話已經(jīng)修改成功。

接下來回到 A 會話查詢記錄：

可以看到，A 會話的記錄也變了。完整測試流程如下：

說好的可重復(fù)讀呢?

按理說，可重復(fù)讀就是別的事務(wù)對數(shù)據(jù)的操作不影響當(dāng)前事務(wù)，但是上面這個案例似乎和我們理解的可重復(fù)讀有出入。

2. 分析

不知道小伙伴們是否還記得可重復(fù)讀的特點：

用戶在另外一個事務(wù)中執(zhí)行同條 SELECT 語句數(shù)次，結(jié)果總是相同的。

從這個角度來說，第一小節(jié)的案例似乎也沒有問題，因為我們在 A 會話中執(zhí)行 SELECT 語句多次，查到的結(jié)果也都是相同的，age 都是 102。

但是我們疑惑的是明明 B 會話的事務(wù)后開啟的，但是我們卻在 A 會話中讀取到了 B 的修改，這似乎不應(yīng)該。

這里就涉及到一個問題，事務(wù)的一致性視圖是何時建立的?

事實上，我們執(zhí)行的 begin 語句并不是一個事務(wù)真正的起點。執(zhí)行完 begin 之后，接下來執(zhí)行的第一句 SQL，事務(wù)才真正啟動。

我們稍微修改一下第一小節(jié)的案例：

在 A 會話中，事務(wù)開啟之后，立馬先執(zhí)行一條 SELECT 語句，然后再去 B 會話中做修改，修改完成后再回到 A 會話繼續(xù)查詢，此時發(fā)現(xiàn) B 中的修改對 A 并不可見，這個結(jié)果也符合用戶在另外一個事務(wù)中執(zhí)行同條 SELECT 語句數(shù)次，結(jié)果總是相同的。

如果我們想要執(zhí)行完 begin 之后，就立馬開啟事務(wù)，那么可以通過如下方式來執(zhí)行：

start transaction with consistent snapshot; 

這個 SQL 執(zhí)行完之后，事務(wù)立馬就啟動了。

接下來，回到第一小節(jié)的案例，我們修改一下事務(wù)啟動的命令：

此時，A 會話中事務(wù)的查詢就看不見 B 中的修改了。

3.小結(jié)

好啦，一個小小的案例，希望小伙伴們在做實驗的時候不要出錯。本文涉及到一個概念叫做一致性視圖，如果大家不熟悉可以參考上篇文章。