正文

讀臟數(shù)據(jù)和不可重復讀（讀臟數(shù)據(jù)和不可重復讀解決）

發(fā)布時間：2023-04-14 01:29:24 稿源：創(chuàng)意嶺閱讀： 78

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關于讀臟數(shù)據(jù)和不可重復讀的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關鍵詞，就能返回你想要的內容，越精準，寫出的就越詳細，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內優(yōu)秀的企業(yè)，服務客戶遍布全球各地，如需了解SEO相關業(yè)務請撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、數(shù)據(jù)庫：為什么一級封鎖協(xié)議不能保證不讀臟數(shù)據(jù)？在修改的時候不是已經(jīng)加了X鎖了嗎為什么其他事務還能讀
2、SQL多用戶訪問數(shù)據(jù)庫怎樣解決沖突？
3、Access數(shù)據(jù)庫中如何避免臟數(shù)據(jù)
4、并發(fā)操作可能會產(chǎn)生哪幾類數(shù)據(jù)不一致?用什么方法能避免各種不一樣的情況?

讀臟數(shù)據(jù)和不可重復讀（讀臟數(shù)據(jù)和不可重復讀解決）

一、數(shù)據(jù)庫：為什么一級封鎖協(xié)議不能保證不讀臟數(shù)據(jù)？在修改的時候不是已經(jīng)加了X鎖了嗎為什么其他事務還能讀

一級封鎖協(xié)議是：事務T在修改數(shù)據(jù)R之前必須先對其加X鎖，直到事務結束才釋放。事務結束包括正常結束（COMMIT）和非正常結束（ROLLBACK）。

注意，該協(xié)議是規(guī)定在修改數(shù)據(jù)R之前必須加鎖。所以如果事務T僅是讀數(shù)據(jù)而不對其進行修改，是不需要加鎖的；事務T在修改R之前，其他事務是能對R進行讀取的，所以它不能保證可重復讀和不讀“臟”數(shù)據(jù)。

二、SQL多用戶訪問數(shù)據(jù)庫怎樣解決沖突？

sql多用戶訪問數(shù)據(jù)庫其實就是事務并發(fā)，會引起如下問題：x0dx0a1、臟讀：一個事務讀取到了另外一個事務沒有提交的數(shù)據(jù)x0dx0a事務1：更新一條數(shù)據(jù)x0dx0a事務2：讀取事務1更新的記錄x0dx0a事務1：調用commit進行提交x0dx0a此時事務2讀取到的數(shù)據(jù)是保存在數(shù)據(jù)庫內存中的數(shù)據(jù)，稱為臟讀。x0dx0a讀到的數(shù)據(jù)為臟數(shù)據(jù)x0dx0a詳細解釋：x0dx0a臟讀就是指:當一個事務正在訪問數(shù)據(jù)，并且對數(shù)據(jù)進行了修改，而這種修改還沒有提交到數(shù)據(jù)庫中，這時，x0dx0a另外一個事務也訪問這個數(shù)據(jù)，然后使用了這個數(shù)據(jù)。因為這個數(shù)據(jù)是還沒有提交的數(shù)據(jù)，那么另外一個x0dx0a事務讀到的這個數(shù)據(jù)是臟數(shù)據(jù)，依據(jù)臟數(shù)據(jù)所做的操作可能是不正確的。x0dx0a2、不可重復讀：在同一事務中，兩次讀取同一數(shù)據(jù)，得到內容不同x0dx0a事務1：查詢一條記錄x0dx0a事務2：更新事務1查詢的記錄x0dx0a事務2：調用commit進行提交x0dx0a事務1：再次查詢上次的記錄x0dx0a此時事務1對同一數(shù)據(jù)查詢了兩次，可得到的內容不同，稱為不可重復讀。x0dx0a3、幻讀：同一事務中，用同樣的操作讀取兩次，得到的記錄數(shù)不相同x0dx0a事務1：查詢表中所有記錄x0dx0a事務2：插入一條記錄x0dx0a事務2：調用commit進行提交x0dx0a事務1：再次查詢表中所有記錄x0dx0a此時事務1兩次查詢到的記錄是不一樣的，稱為幻讀x0dx0a詳細解釋：x0dx0a幻讀是指當事務不是獨立執(zhí)行時發(fā)生的一種現(xiàn)象，例如第一個事務對一個表中的數(shù)據(jù)進行了修改，x0dx0a這種修改涉及到表中的全部數(shù)據(jù)行。同時，第二個事務也修改這個表中的數(shù)據(jù)，這種修改是向表x0dx0a中插入一行新數(shù)據(jù)。那么，以后就會發(fā)生操作第一個事務的用戶發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行，x0dx0a就好象發(fā)生了幻覺一樣。x0dx0a處理以上隔離級別的問題，采用如下方是：x0dx0a事務隔離五種級別：x0dx0aTRANSACTION_NONE不使用事務。x0dx0aTRANSACTION_READ_UNCOMMITTED允許臟讀。x0dx0aTRANSACTION_READ_COMMITTED防止臟讀，最常用的隔離級別,并且是大多數(shù)數(shù)據(jù)庫的默認隔離級別x0dx0aTRANSACTION_REPEATABLE_READ可以防止臟讀和不可重復讀，x0dx0aTRANSACTION_SERIALIZABLE可以防止臟讀，不可重復讀取和幻讀，（事務串行化）會降低數(shù)據(jù)庫的效率x0dx0a以上的五個事務隔離級別都是在Connection接口中定義的靜態(tài)常量，x0dx0a使用setTransactionIsolation(intlevel)方法可以設置事務隔離級別。x0dx0a如:con.setTransactionIsolation(Connection.REPEATABLE_READ);x0dx0a注意：事務的隔離級別受到數(shù)據(jù)庫的限制，不同的數(shù)據(jù)庫支持的的隔離級別不一定相同x0dx0a1臟讀：修改時加排他鎖，直到事務提交后才釋放，讀取時加共享鎖，讀取完釋放事務1讀取數(shù)據(jù)時加上共享鎖后（這樣在事務1讀取數(shù)據(jù)的過程中，其他事務就不會修改該數(shù)據(jù)），不允許任何事物操作該數(shù)據(jù)，只能讀取，之后1如果有更新操作，那么會轉換為排他鎖，其他事務更無權參與進來讀寫，這樣就防止了臟讀問題。x0dx0a但是當事務1讀取數(shù)據(jù)過程中，有可能其他事務也讀取了該數(shù)據(jù)，讀取完畢后共享鎖釋放，此時事務1修改數(shù)據(jù)，修改完畢提交事務，其他事務再次讀取數(shù)據(jù)時候發(fā)現(xiàn)數(shù)據(jù)不一致，就會出現(xiàn)不可重復讀問題，所以這樣不能夠避免不可重復讀問題。x0dx0a2不可重復讀：讀取數(shù)據(jù)時加共享鎖，寫數(shù)據(jù)時加排他鎖，都是事務提交才釋放鎖。讀取時候不允許其他事物修改該數(shù)據(jù)，不管數(shù)據(jù)在事務過程中讀取多少次，數(shù)據(jù)都是一致的，避免了不可重復讀問題x0dx0a3幻讀問題：采用的是范圍鎖RangeSRangeS_S模式，鎖定檢索范圍為只讀，這樣就避免了幻影讀問題。

三、Access數(shù)據(jù)庫中如何避免臟數(shù)據(jù)

臟讀dirty reads：當事務讀取還未被提交的數(shù)據(jù)時，就會發(fā)生這種事件。舉例來說：Transaction 1 修改了一行數(shù)據(jù)，然后 Transaction 2 在 Transaction 1 還未提交修改操作之前讀取了被修改的行。如果 Transaction 1 回滾了修改操作，那么 Transaction 2 讀取的數(shù)據(jù)就可以看作是從未存在過的。

不可重復的讀non-repeatable reads：當事務兩次讀取同一行數(shù)據(jù)，但每次得到的數(shù)據(jù)都不一樣時，就會發(fā)生這種事件。舉例來說：Transaction 1 讀取一行數(shù)據(jù)，然后 Transaction 2 修改或刪除該行并提交修改操作。當 Transaction 1 試圖重新讀取該行時，它就會得到不同的數(shù)據(jù)值（如果該行被更新）或發(fā)現(xiàn)該行不再存在（如果該行被刪除）。

虛讀phantom read：如果符合搜索條件的一行數(shù)據(jù)在后面的讀取操作中出現(xiàn)，但該行數(shù)據(jù)卻不屬于最初的數(shù)據(jù)，就會發(fā)生這種事件。舉例來說：Transaction 1 讀取滿足某種搜索條件的一些行，然后 Transaction 2 插入了符合 Transaction 1 的搜索條件的一個新行。如果 Transaction 1 重新執(zhí)行產(chǎn)生原來那些行的查詢，就會得到不同的行。

MYSQL事務隔離級別的認識

2010-08-06 10:27

在hibernate中如果要連續(xù)不間斷的保存多個實體的實例，那么在我們保存第一個的時候，其實在數(shù)據(jù)庫里是不存在數(shù)據(jù)的，即使用Session.flush()也無濟于事，這到底是怎么回事呢？讓我很是疑惑.......

在查閱了相關的資料后，原來是數(shù)據(jù)庫對于事務的隔離級別的限制問題，而我原來的MYSQL數(shù)據(jù)庫正好是不支持我上述操作的隔離級別。

1、在MYSQL中查詢事務隔離級別：

select @@tx_isolation;（tx其實就是transaction的縮寫或者習慣縮寫法）

我的結果是REPEATABLE-READ（即可重復讀，稍后會引用專業(yè)結束文檔）

2、修改MYSQL事務隔離界別：

set transaction isolation level 目標隔離級別;

3、再次查詢隔離級別進行檢驗是否已經(jīng)成功修改。

這樣在修改了隔離級別之后，在進行save()的時候，數(shù)據(jù)庫中就會存在一些數(shù)據(jù)了，問題解決了。關于其他的數(shù)據(jù)庫產(chǎn)品，思想都是一樣的。

附加、官方的SQL事務隔離級別文檔：

SQL標準定義了4類隔離級別，包括了一些具體規(guī)則，用來限定事務內外的哪些改變是可見的，哪些是不可見的。低級別的隔離級一般支持更高的并發(fā)處理，并擁有更低的系統(tǒng)開銷。

Read Uncommitted（讀取未提交內容）

在該隔離級別，所有事務都可以看到其他未提交事務的執(zhí)行結果。本隔離級別很少用于實際應用，因為它的性能也不比其他級別好多少。讀取未提交的數(shù)據(jù)，也被稱之為臟讀（Dirty Read）。

Read Committed（讀取提交內容）

這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認隔離級別（但不是MySQL默認的）。它滿足了隔離的簡單定義：一個事務只能看見已經(jīng)提交事務所做的改變。這種隔離級別也支持所謂的不可重復讀（Nonrepeatable Read），因為同一事務的其他實例在該實例處理其間可能會有新的commit，所以同一select可能返回不同結果。

Repeatable Read（可重讀）

這是MySQL的默認事務隔離級別，它確保同一事務的多個實例在并發(fā)讀取數(shù)據(jù)時，會看到同樣的數(shù)據(jù)行。不過理論上，這會導致另一個棘手的問題：幻讀（Phantom Read）。簡單的說，幻讀指當用戶讀取某一范圍的數(shù)據(jù)行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的數(shù)據(jù)行時，會發(fā)現(xiàn)有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本并發(fā)控制（MVCC，Multiversion Concurrency Control）機制解決了該問題。

Serializable（可串行化）

這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數(shù)據(jù)行上加上共享鎖。在這個級別，可能導致大量的超時現(xiàn)象和鎖競爭。

四、并發(fā)操作可能會產(chǎn)生哪幾類數(shù)據(jù)不一致?用什么方法能避免各種不一樣的情況?

大致會產(chǎn)生三類：1、丟失更新2、不可重復讀3、讀“臟”數(shù)據(jù)。解決方法：封鎖：排他鎖（X鎖），共享鎖（S鎖），三級封鎖協(xié)議，兩段鎖協(xié)議（2PL），其他的我也不清楚了，這些也是我在書上看的，不要見怪！

以上就是關于讀臟數(shù)據(jù)和不可重復讀相關問題的回答。希望能幫到你，如有更多相關問題，您也可以聯(lián)系我們的客服進行咨詢，客服也會為您講解更多精彩的知識和內容。