最近回頭看事務，突然發現一個問題：
很多的資料都說四個隔離級別都解決了第一類更新丟失的問題(回滾覆寫)，但是找了很多資料也沒找到 在 讀未提交 隔離級別下，是怎么解決掉回滾覆寫這個問題的
比如在mysql - innoDB下，read uncommited 級別是讀不會申請鎖，寫申請長鎖 - 排它鎖，這樣就能解決了回滾覆寫？
而且比如兩個事務并發：
T1開始事務 -> T2開始事務 -> T2 更新資料X 并commit -> T1更新資料X，然后回滾
上面T1和T2的并發就會造成T2更新的資料消失，這種情況在讀未提交的級別下怎么可能會不出現呢？完全可以出現啊？為什么那么多資料都說 四種隔離級別都不會出現 “第一類更新丟失”呢？
uj5u.com熱心網友回復：
read uncommited 這個級別的意思是一個事務可以讀取到另一個事務未執行commit的資料。以你的例子來說，T2讀取了T1未提交的資料，T2完成提交后，T1回滾資料。這導致T2讀取到的資料不是實際發生的資料。可能引發邏輯上判斷的事務。這個現象有個名字，臟資料。個人認為，更新丟失的說法容易引起誤解，用臟資料來說明會更清楚。其他的隔離界別限制了未提交資料不可讀取，也就不會出現臟資料了。但是還有其他問題，比如說重復讀問題。T1事務執行讀取資料，T2事務執行修改了T1讀取的資料并成功提交，而T1可能再一次讀取該資料發現資料已經變化了，這樣就導致前后不一致了。
uj5u.com熱心網友回復：
麻煩看一下流程
T1開始事務 -> T2開始事務 -> T2 更新資料X 并commit -> T1更新資料X，然后回滾
沒有涉及到讀，所以你回答中 “導致T2讀取到的資料不是實際發生的資料” 這個讀是哪來的呢？
你可能先得搞清楚什么是第一類更新丟失和第二類更新丟失再來回答問題
uj5u.com熱心網友回復：
抱歉你這個問題跟鎖有關。如果T1先對X加排它鎖，那么T2實際上是要等待T1完成事務后才會執行，就是發生了阻塞。
如果T1執行中還沒加排它鎖，T2對X加排它鎖，那么T1就會等待T2完成后才能執行，也是阻塞。
對同一資料物件進行更新操作，總會有先有后，最后一個執行成功的就是最終結果。
隔離級別是事務執行中，資料變化對其他事務的影響。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/19844.html
標籤：MySQL
上一篇：觸發器跨表計算總價格