目錄
四、其他:mysql innodb 引擎 rr 隔離級別是否解決了幻讀
五、注意
在一次事務裡面,多次查詢之後,結果集的個數不一致的情況叫做幻讀。而多或者少的那一行被叫做幻行
在高併發資料庫系統中,需要保證事務與事務之間的隔離性,還有事務本身的一致性。
如果你看到了這篇文章,那麼我會預設你了解了髒讀
、不可重複讀
與可重複讀
。
多數資料庫都實現了多版本併發控制,並且都是靠儲存資料快照來實現的。
以innodb
為例。可以理解為每一行中都冗餘了兩個字段,乙個是行的建立版本,乙個是行的刪除(過期)版本。
具體的版本號(trx_id)存在information_schema.innodb_trx
表中。
版本號(trx_id)隨著每次事務的開啟自增。
事務每次取資料的時候都會取建立版本小於當前事務版本的資料,以及過期版本大於當前版本的資料。
普通的 select 就是快照讀。
select * from t where number = 1;
原理:將歷史資料存乙份快照,所以其他事務增加與刪除資料,對於當前事務來說是不可見的。
next-key 鎖包含兩部分
記錄鎖是加在索引上的鎖,間隙鎖是加在索引之間的。(思考:如果列上沒有索引會發生什麼?)
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
解決了幻讀問題。
不能把快照讀和當前讀得到的結果不一樣這種情況認為是幻讀,這是兩種不同的使用方式。所以認為mysql
的rr
級別是解決了幻讀的。
先說結論,mysql
儲存引擎innodb
隔離級別rr
解決了幻讀問題。
如引用一問題所說,t1select
之後update
,會將 t2 中insert
的資料一起更新,那麼認為多出來一行,所以防不住幻讀。但是其實這種方式是一種bad case
。如圖:
next-key
固然很好的解決了幻讀問題,但是還是遵循一般的定律,隔離級別越高,併發越低。
MySQL 是如何解決幻讀的
在一次事務裡面,多次查詢之後,結果集的個數不一致的情況叫做幻讀。而多或者少的那一行被叫做幻行 在高併發資料庫系統中,需要保證事務與事務之間的隔離性,還有事務本身的一致性。如果你看到了這篇文章,那麼我會預設你了解了髒讀 不可重複讀與可重複讀。多數資料庫都實現了多版本併發控制,並且都是靠儲存資料快照來實...
Mysql如何解決幻讀
日常開發中接觸到最多的事務隔離級別分別是read committed和repeatable read也就是我們常說的提交讀和可重複讀。innodb的rr級別和rc級別最大的區別就是增加了gap鎖也就是間隙鎖,那麼間隙鎖是如何解決幻讀的呢?回憶一下幻讀和髒讀的概念,髒讀就是,乙個事物讀到了另乙個事務未...
談談MySQL是如何解決幻讀問題的?
事務的隔離級別有四種,讀未提交,讀已提交,可重複讀和序列化,下面結合具體的問題,在mysql中,innodb引擎是怎麼解決幻讀的?一張圖勝過千言萬語 1,什麼是幻讀?2,為什麼要解決幻讀?3,mysql是怎麼解決幻讀的?3.1next key原理是什麼?3.2 next key鎖包含什麼?4,mys...