我們知道在 RR 級別下，重復的 select 操作，讀取的值都會是一致的。即便在兩次 select 操作的中間，有一個事務 B 修改了值，但是在事務 A 中 select 讀取的值還是一致的。

那么如果是 update 操作呢？之前在網上看到一篇博客說 RR 級別下，CAS 操作是沒有意義的。因為 version 值在一個事務中都是一致不變的。于是我有了疑惑打算自己來驗證一下。

驗證想法

RR 級別下 update 操作的是快照讀還是當前讀？

準備數據

準備了以下簡單的表數據結構。

sid

name

sex

version

1

zhangsan

0

0

2

lisi

1

0

驗證思路

通過 version 值做 CAS 版本，修改 sex 值。

A 事務先執行，通過 sleep 5 秒延遲最后的 update 操作。

B 事務后執行，通過 sleep 1 秒使得它雖然事務 id 更大，但比 A 事務更早執行完成。

查看 A 事務通過 version 字段 CAS 操作能否修改成功 sex 值。

如果能修改成功即 update 語句 where 條件定位的是快照讀，反之則定位的是當前讀。

事務腳本

事務 A

事務 A 先執行，事務 id 小

begin;

SELECT version from student where sid = 1;

// 當前獲取的version為0

SELECT SLEEP(5);

SELECT version from student where sid = 1;

// 此時獲取的version依然為0

update student set sex = 1 , version = version +1 where sid = 1 and version = 0;

// 修改行數為0，修改操作失敗，說明version已經不是0了，

commit;

事務 B

事務 B 后執行，事務 id 大

begin;

SELECT version from student where sid = 1;

// 當前獲取的version為0

SELECT SLEEP(1);

SELECT version from student where sid = 1;

// 此時獲取的version依然為0

update student set sex = 2 , version = version +1 where sid = 1 and version = 0;

// 修改成功，此時當前version為1

commit;

驗證結果

事務 A 的 update 操作失敗，說明 update 中的 where 條件定位的記錄是當前讀而非快照讀。

總結

以上是生活随笔為你收集整理的mysql rr 更新失败_RR 级别下 update 操作的是快照读还是当前读？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。