資料庫隔離機制的實現
總結糾正個問題
資料資料庫隔離機制
序列化可重複讀
讀已提交
讀未提交
資料庫事務可能導致的問題
髒讀不可重複讀幻讀
髒讀 事務a，先執行，處於未提交的狀態：
insert into table values(1, xx);
事務b，後執行，也未提交：
select * from table ;
如果事務b能夠讀取到(1, xx)這條記錄，事務a就對事務b產生了影響，這個影響叫做「髒讀」，讀到了未提交事務操作的記錄。
不可重複讀
事務a，先執行：
select * from table where id=1;
結果集為：
1, xx
事務b，後執行，並且提交：
update table set name=yy where id=1;
commit;
事務a，再次執行相同的查詢：
select * from table where id=1;
結果集為：
1, yy
這次是已提交事務b對事務a產生的影響，這個影響叫做「不可重複讀」，乙個事務內相同的查詢，得到了不同的結果。
和髒讀區別在於，髒讀在於讀事務b還沒有提交的資料，而不可重讀是讀取到事務b已經提交的資料
幻讀 事務a，先執行：
update table set name=「hh」 where id>3;
結果為：
ok row xx 表名成功影響多少行資料
事務b，後執行，並且提交：
insert into table values(11, uu);
commit;
事務a，然後再select一下：
select * from table where id>3
結果集為：
11,uu
事務a懵了，我特麼不是id>3全部更新了嗎
這次是已提交事務b對事務a產生的影響，這個影響叫做「幻讀」。
資料庫隔離機制的實現
一、讀未提交
這個玩意應該沒人使用，完全性的不加鎖，select不加鎖。最爽，最快，可惜資料髒讀
二、序列化
這個最安全，select都是加鎖，所有select語句都會被隱式的轉化為in share mode. 這就意味著，如果前面有事務在做修改操作，那麼就會阻塞。完全性的把讀和寫序列化了。但是這個併發性不高
三、讀已提交
最使用最廣的隔離機制
普通讀是快照讀，mvvc每次讀取都是讀取當前快照最新版本，會自動重新整理，所以讀取其他事務已經提交了的
加鎖的select, update, delete等語句，除了在外來鍵約束檢查以及重複鍵檢查時會封鎖區間，其他時刻都只使用記錄鎖；
此時，其他事務的插入依然可以執行，就可能導致，讀取到幻影記錄。也就是說一般都是記錄鎖，鎖單記錄，上面那個幻讀例子中，id>3的有5條記錄，只會單獨鎖5條，插入11的時候還是不會鎖住。
四、可重複讀
這是innodb預設的隔離級別
普通的select使用快照讀，mvvc讀取建立版本小於或等於當前事務版本號，並且刪除版本為空或大於當前事務版本號的記錄。這樣可以保證在讀取之前記錄是存在的。解決幻讀和不可重複讀
加鎖的select(s或者x), update, delete等語句，它們的鎖，依賴於它們是否在唯一索引上使用了唯一的查詢條件，或者範圍查詢條件： 總結
糾正個問題
大多數資料上說幻讀只能序列化解決，而可重複讀只能解決不可重複讀，解決不了幻讀。
在《mysql技術內幕，innodb儲存引擎》 事務解釋，innodb預設的可重複讀的事務隔離機制，採用的是next-key lock(臨鍵鎖) 鎖定範圍，因此避免了幻讀
資料
資料庫鎖機制實現隔離
面對高併發加鎖可以從兩種層面來考慮 下面介紹 樂觀鎖 悲觀鎖 共享鎖s和排他鎖x 區別 1.樂觀鎖 從上面的例子可以看出，樂觀鎖機制避免了長事務中的資料庫加鎖開銷 操作員 a和操作員 b 操作過程中，都沒有對資料庫資料加鎖 大大提公升了大併發量下的系統整體效能表現。需要注意的是，樂觀鎖機制往往基於系...
資料庫的隔離機制
1 併發環境下資料庫可能出現的四種情況 1 丟失更新 兩個事務同時對同乙份資料進行修改，其中乙個事務的修改被另外乙個事務覆蓋 2 髒讀 事務a對資源t進行了更新，事務b讀到了更新後的t，但事務a卻rollback導致更新無效 此時b讀到的t是髒的 3 不可重複讀 事務a讀取資源t，在a結束之前，多次...
資料庫事物 隔離等級及資料庫鎖機制
事務 transaction 是資料庫管理系統的執行單位，可以是乙個資料庫操作 如select操作 或者是一組操作序列。事務acid屬性，即原子性 atomicity 一致性 consistency 隔離性 isolation 永續性 durability 原子性 atomic 保證事務中的所有操作...