數(shù)據(jù)庫哪個隔離級別可以實現(xiàn)臟讀？對于同時運(yùn)行的多個事務(wù)， 當(dāng)這些事務(wù)訪問數(shù)據(jù)庫中相同的數(shù)據(jù)時， 如果沒有采取必要的隔離機(jī)制， 就會導(dǎo)致各種并發(fā)問題: ? 臟讀: 對于兩個事物 T1， T2， T

數(shù)據(jù)庫哪個隔離級別可以實現(xiàn)臟讀？

對于同時運(yùn)行的多個事務(wù)， 當(dāng)這些事務(wù)訪問數(shù)據(jù)庫中相同的數(shù)據(jù)時， 如果沒有采取必要的隔離機(jī)制， 就會導(dǎo)致各種并發(fā)問題: ? 臟讀: 對于兩個事物 T1， T2， T1 讀取了已經(jīng)被 T2 更新但還沒有被提交的字段. 之后， 若 T2 回滾， T1讀取的內(nèi)容就是臨時且無效的. ? 不可重復(fù)讀: 對于兩個事物 T1， T2， T1 讀取了一個字段， 然后 T2 更新了該字段. 之后， T1再次讀取同一個字段， 值就不同了. ? 幻讀: 對于兩個事物 T1， T2， T1 從一個表中讀取了一個字段， 然后 T2 在該表中插入了一些新的行. 之后， 如果 T1 再次讀取同一個表， 就會多出幾行. 數(shù)據(jù)庫事務(wù)的隔離性: 數(shù)據(jù)庫系統(tǒng)必須具有隔離并發(fā)運(yùn)行各個事務(wù)的能力， 使它們不會相互影響， 避免各種并發(fā)問題. 一個事務(wù)與其他事務(wù)隔離的程度稱為隔離級別. 數(shù)據(jù)庫規(guī)定了多種事務(wù)隔離級別， 不同隔離級別對應(yīng)不同的干擾程度， 隔離級別越高， 數(shù)據(jù)一致性就越好， 但并發(fā)性越弱 數(shù)據(jù)庫提供了4中隔離級別： 隔離級別 描述 READ UNCOMMITTED(讀未提交數(shù)據(jù)) 允許事務(wù)讀取未被其他事務(wù)提交的變更，臟讀、不可重復(fù)讀和幻讀的問題都會出現(xiàn) READ COMMITED(讀已提交數(shù)據(jù)) 只允許事務(wù)讀取已經(jīng)被其他事務(wù)提交的變更，可以避免臟讀，但不可重復(fù)讀和幻讀問題仍然會出現(xiàn) REPEATABLE READ(可重復(fù)讀) 確保事務(wù)可以多次從一個字段中讀取相同的值，在這個事務(wù)持續(xù)期間，禁止其他事務(wù)對這個字段進(jìn)行更新，可以避免臟讀和不可重復(fù)讀，但幻讀的問題依然存在 SERIALIZABLE(串行化) 確保事務(wù)可以從一個表中讀取相同的行，在這個事務(wù)持續(xù)期間，禁止其他事務(wù)對該表執(zhí)行插入、更新和刪除操作，所有并發(fā)問題都可以避免，但性能十分低 Oracle 支持的 2 種事務(wù)隔離級別：READ COMMITED， SERIALIZABLE. Oracle 默認(rèn)的事務(wù)隔離級別為: READ COMMITED Mysql 支持 4 中事務(wù)隔離級別. Mysql 默認(rèn)的事務(wù)隔離級別為: REPEATABLE READ

MySQL的可重復(fù)讀級別能解決幻讀嗎？

現(xiàn)在的主流數(shù)據(jù)庫都使用MVCC，用了之后的RR隔離級別是不會出現(xiàn)幻讀的。

不同的資料講的RR是199X年的ANSI SQL標(biāo)準(zhǔn)，但現(xiàn)實的數(shù)據(jù)庫不一定符合標(biāo)準(zhǔn)（事實上，沒有幻讀是更好的事情）。

如何保證多線程從mysql數(shù)據(jù)庫查詢的數(shù)據(jù)不重復(fù)？

以mysql來說，可能出現(xiàn)臟讀、不可重復(fù)讀以及幻讀，mysql默認(rèn)設(shè)置是可重復(fù)讀，即一次事務(wù)中不會讀取到不同的數(shù)據(jù)?？梢宰鋈缦虏僮鳎?/p>

1）打開兩個客戶端，均設(shè)置為RR；

2）在一個事務(wù)中，查詢某個操作查到某份數(shù)據(jù)；比如是某個字段version=1存在數(shù)據(jù)；

3）在另一個事務(wù)中，刪除這份version=1的數(shù)據(jù)；刪除后，在2所屬的事務(wù)中查詢數(shù)據(jù)是沒有變化的，還是存在version=1的數(shù)據(jù)；

4）當(dāng)我們在2所屬的事務(wù)中繼續(xù)更新數(shù)據(jù)，那么會發(fā)現(xiàn)更新不了，明明我們就看到了這份version=1的數(shù)據(jù)；緩存一致性:緩存一致，與什么一致？是與數(shù)據(jù)庫一致，對外查詢每個時刻一致；所以在針對于緩存與數(shù)據(jù)庫之間該先更新哪一個呢？可能有人覺得我先更新數(shù)據(jù)庫，再更新緩存不就行了嗎？但是有想過個問題嗎？當(dāng)用戶已經(jīng)支付成功了，更新到數(shù)據(jù)庫，但是呢？你還在緩存中顯示未支付，在用戶點擊頻率很高并且數(shù)據(jù)庫壓力過大，來不及同步到緩存時，那你是不是很尷尬，這就是典型的不一致了。此時用戶再支付，那你又告訴他已經(jīng)支付了，那他會把你罵死的那該怎么來做呢？我們可以這樣，先更新緩存再更新數(shù)據(jù)庫，那么存在什么問題呢？1）緩存更新成功，但是數(shù)據(jù)庫更新失敗，而被其它的并發(fā)線程訪問到2）緩存淘汰成功，但是數(shù)據(jù)庫更新失敗，這也會引發(fā)后期數(shù)據(jù)不一致