1.數(shù)據(jù)庫隔離級別
目前數(shù)據(jù)庫MySQL 并發(fā)事務下,在不同的隔離級別下,可能會出現(xiàn)四個問題.分別是:臟寫(Lost Update),臟讀(Dirty Reads),不可重復讀(Non-Repeatable Reads),幻讀(Phantom Reads)。
數(shù)據(jù)庫的隔離級別分別是: 未提交讀(read uncommitted)、已提交讀(read committed)、可重復讀(repeatable read)、串行化(serializable)
2.各種數(shù)據(jù)庫引擎的默認隔離級別
- Mysql 可重復讀
- Oracle 讀提交
- Sql Server 讀提交
為什么Oracle和Sql Server的默認隔離級別是可提交？為什么Mysql是可重復讀？
首先隔離級別肯定不能是未提交讀，讀取未提交的數(shù)據(jù)太過危險。串行化的隔離級別基本意味著沒有高并發(fā)，太嚴格。所以隔離級別就在已提交讀和可重復讀之間了。那么大多數(shù)的選擇是已讀提交，這是因為：
（1）repeatable存在間隙鎖會使死鎖的概率增大，在RR隔離級別下，條件列未命中索引會鎖表！而在RC隔離級別下，只鎖行。
（2）在RC級用別下，主從復制用什么binlog格式：row格式，是基于行的復制！
那為什么，在Oracle，SqlServer中都是選擇讀已提交(Read Commited)作為默認的隔離級別，為什么Mysql不選擇讀已提交(Read Commited)作為默認隔離級別，而選擇可重復讀(Repeatable Read)作為默認的隔離級別呢？
詳細說明見：https://www.cnblogs.com/shoshana-kong/p/10516404.html
3.隔離級別舉例
見 https://zhuanlan.zhihu.com/p/150107974
4.事務隔離級別是如何避免上述讀寫問題
（1）讀未提交：一個事務可以讀取到另一個事務未提交的修改。這會帶來臟讀、幻讀、不可重復讀問題。（基本沒用）
（2）讀已提交：一個事務只能讀取另一個事務已經提交的修改。其避免了臟讀，但仍然存在不可重復讀和幻讀問題。
（3）可重復讀：同一個事務中多次讀取相同的數(shù)據(jù)返回的結果是一樣的。其避免了臟讀和不可重復讀問題，但幻讀依然存在。
（4）串行化：事務串行執(zhí)行。避免了以上所有問題。
以上是SQL-92標準中定義的四種隔離級別。在MySQL中，默認的隔離級別是REPEATABLE-READ（可重復讀），并且解決了幻讀問題。簡單的來說，mysql的默認隔離級別解決了臟讀、幻讀、不可重復讀問題。
不可重復讀重點在于update和delete，而幻讀的重點在于insert。
在這里，我們只討論讀已提交和可重復讀。
我們可以通過MVCC，即多版本并發(fā)控制，來實現(xiàn)讀已提交和可重復讀的隔離機制。
MVCC如何實現(xiàn)數(shù)據(jù)庫讀已提交和可重復讀這兩種隔離級別？
MVCC其實主要包含三個概念：隱藏列，undo log，ReadView
隱藏列
在Innodb引擎中，每個數(shù)據(jù)表都會有兩個隱藏列（其實準確來說是三個，還有一個叫隱藏id，因為innodb必須要有主鍵，如果建表時沒有顯式指定的話，就會生成這個隱藏id作為主鍵，當然這個隱藏id和mvcc沒有關系，真正和mvcc有關系的其實是兩個隱藏列），分別是trx_id,創(chuàng)建版本號；和roll_pointer，回滾指針。其中創(chuàng)建版本號其實就是創(chuàng)建該行數(shù)據(jù)的事務id。這些隱藏列對我們客戶端來說是不可見的。
undo log
當事務對數(shù)據(jù)行進行一次更新操作時，會把舊數(shù)據(jù)行記錄在一個叫做undo log的記錄中，在undo log中除了記錄數(shù)據(jù)行，還會記錄下該行數(shù)據(jù)的對應的創(chuàng)建版本號，也就是生成這行數(shù)據(jù)的事務id嘛~然后將原來數(shù)據(jù)行中的回滾指針指向undo log記錄的這行數(shù)據(jù)。然后再在原來數(shù)據(jù)表中進行一次更新操作，如果這次更新操作回滾了，那么就可以根據(jù)回滾指針去undo log中查找之前的數(shù)據(jù)進行復原。如果后續(xù)還有更新操作的話，就會在undo log中和之前的數(shù)據(jù)行形成一條鏈表，鏈表頭就是最新的數(shù)據(jù)，這條鏈表就叫做版本鏈
（ps：數(shù)據(jù)本來是劉備，然后事務id為100的事務先修改成了關羽，再修改成了張飛，后面事務id為200的事務先修改成了趙云，再修改成了諸葛亮，）
事務的可見性都是基于這個undo log來實現(xiàn)的
ReadView
剛才說了更新操作，那查詢操作呢？這才是實現(xiàn)不同隔離級別的關鍵地方
當進行查詢操作時，事務會生成一個ReadView，ReadView是一個事務快照，準確來說是當前時間點系統(tǒng)內活躍的事務列表，也就是說系統(tǒng)內所有未提交的事務，都會記錄在這個Readview內，事務就根據(jù)它來判斷哪些數(shù)據(jù)是可見的，哪些是不可見的。
查詢一條數(shù)據(jù)時，事務會拿到這個ReadView，去到undo log中進行判斷。若查詢到某一條數(shù)據(jù)：
- 先去查看undo log中的最新數(shù)據(jù)行，如果數(shù)據(jù)行的版本號小于ReadView記錄的事務id最小值，就說明這條數(shù)據(jù)對當前數(shù)據(jù)庫是可見的，可以直接作為結果集返回
- 若數(shù)據(jù)行版本號大于ReadView記錄最大值，說明這條數(shù)據(jù)是由一個新的事務修改的，對當前事務不可見，那么就順著版本鏈繼續(xù)往下尋找第一條滿足條件的
- 若數(shù)據(jù)行版本號在ReadView最小值和最大值之間，那么就需要進行遍歷了整個ReadView了，如果數(shù)據(jù)行版本號等于ReadView的某個值，說說明該行數(shù)據(jù)仍然處于活躍狀態(tài)，那么對當前事務不可見
讀已提交和可重復讀的實現(xiàn)
ReadView就是這樣來判斷數(shù)據(jù)可見性的。
那又是如何實現(xiàn)讀已提交和可重復讀呢？其實很簡單，就是生成ReadView的時機不同。
對讀已提交來說，事務中的每次讀操作都會生成一個新的ReadView，也就是說，如果這期間某個事務提交了，那么它就會從ReadView中移除。這樣確保事務每次讀操作都能讀到相對比較新的數(shù)據(jù)
而對可重復讀來說，事務只有在第一次進行讀操作時才會生成一個ReadView，后續(xù)的讀操作都會重復使用這個ReadView。也就是說，如果在此期間有其他事務提交了，那么對于可重復讀來說也是不可見的，因為對它來說，事務活躍狀態(tài)在第一次進行讀操作時就已經確定下來，后面不會修改了。
（引用：https://www.pianshen.com/article/89531041786/）
