MySQL 到底是怎麼解決幻讀的?

2021-09-24 03:16:29 字數 1796 閱讀 2234

在一次事務裡面,多次查詢之後,結果集的個數不一致的情況叫做幻讀。而多出來或者少的哪一行被叫做幻行。

在高併發資料庫系統中,需要保證事務與事務之間的隔離性,還有事務本身的一致性。

如果你看到了這篇文章,那麼我會預設你了解了髒讀 、不可重複讀與可重複讀。

多數資料庫都實現了多版本併發控制,並且都是靠儲存資料快照來實現的。以 innodb 為例,每一行中都冗餘了兩個字斷。

乙個是行的建立版本,乙個是行的刪除(過期)版本。具體的版本號(trx_id)存在 information_schema.innodb_trx 表中。版本號(trx_id)隨著每次事務的開啟自增。

事務每次取資料的時候都會取建立版本小於當前事務版本的資料,以及過期版本大於當前版本的資料。

普通的 select 就是快照讀。

select * from t where number = 1;

原理:將歷史資料存乙份快照,所以其他事務增加與刪除資料,對於當前事務來說是不可見的。

next-key 鎖包含兩部分:

記錄鎖是加在索引上的鎖,間隙鎖是加在索引之間的。(思考:如果列上沒有索引會發生什麼?)

select * from t where number = 1 for update;

select * from t where number = 1 lock in share mode;

insert

update

delete

mysql官方給出的幻讀解釋是:只要在乙個事務中,第二次select多出了row就算幻讀。

a事務先select,b事務insert確實會加乙個gap鎖,但是如果b事務commit,這個gap鎖就會釋放(釋放後a事務可以隨意dml操作),a事務再select出來的結果在mvcc下還和第一次select一樣,接著a事務不加條件地update,這個update會作用在所有行上(包括b事務新加的),a事務再次select就會出現b事務中的新行,並且這個新行已經被update修改了,實測在rr級別下確實如此。

如果這樣理解的話,mysql的rr級別確實防不住幻讀

在快照讀讀情況下,mysql通過mvcc來避免幻讀。

在當前讀讀情況下,mysql通過next-key來避免幻讀。

select * from t where a=1;屬於快照讀

select * from t where a=1 lock in share mode;屬於當前讀

不能把快照讀和當前讀得到的結果不一樣這種情況認為是幻讀,這是兩種不同的使用。所以我認為mysql的rr級別是解決了幻讀的。

先說結論,mysql 儲存引擎 innodb 隔離級別 rr 解決了幻讀問題。

如引用一問題所說,t1 select 之後 update,會將 t2 中 insert 的資料一起更新,那麼認為多出來一行,所以防不住幻讀。看著說法無懈可擊,但是其實是錯誤的,innodb 中設定了快照讀和當前讀兩種模式,如果只有快照讀,那麼自然沒有幻讀問題,但是如果將語句提公升到當前讀,那麼 t1 在 select 的時候需要用如下語法: select * from t for update (lock in share mode) 進入當前讀,那麼自然沒有 t2 可以插入資料這一回事兒了。

next-key 固然很好的解決了幻讀問題,但是還是遵循一般的定律,隔離級別越高,併發越低。

mysql到底是怎麼解決幻讀的?

mysql到底是怎麼解決幻讀的?mvcc是什麼,怎麼實現的?先理解幾個概念 非鎖定的一致性讀 圖中左邊為非一致性讀部分 非一致性讀 在sql查詢的時候,如果發現記錄已經被加了x鎖,會轉而查詢當前記錄回滾段中最近的快照,讀快照不加鎖,非常快 mvcc 多版本控制 這裡的多版本就是指的回滾段的快照,用來...

MySql系列 MySQL 到底是怎麼解決幻讀的?

什麼是幻讀?在一次事務裡面,多次查詢之後,結果集的個數不一致的情況叫做幻讀。而多出來或者少的哪一行被叫做幻行。為什麼要解決幻讀?在高併發資料庫系統中,需要保證事務與事務之間的隔離性,還有事務本身的一致性。mysql 是如何解決幻讀的?如果你看到了這篇文章,那麼我會預設你了解了髒讀 不可重複讀與可重複...

MySQL談談InnoDB怎麼解決幻讀的

首先說結論,在rr的隔離級別下,innodb使用mvcc和next key locks解決幻讀,mvcc解決的是普通讀 快照讀 的幻讀,next key locks解決的是當前讀情況下的幻讀。事務a,先執行 update table set name hh where id 3 結果為 ok row...