?

數據庫的事務隔離級別：

1.Read Commited 可讀已提交
?? 2.Read Uncommited 可讀未提交
?? 3.Repeatable Read 可重復讀
?? 4.Serializable 串行化

sqlserver默認的事務隔離級別是：讀可提交。

?

各種并發問題

1. 第一類丟失更新(lost update)： 在完全未隔離事務的情況下，兩個事物更新同一條數據資源，某一事物異常終止，回滾造成第一個完成的更新也同時丟失。

?	事務1	事務2
1	開啟事務	?
2	?	開啟事務
3	取出數據 age=20	?
4	?	取出數據 age=20
5	更新數據 age=30	?
6	?	更新數據 age=35，并提交事務
7	回滾事務	?

?

?

在T1時刻開啟了事務1，T2時刻開啟了事務2，在T3時刻事務1從數據庫中取出了id="402881e535194b8f0135194b91310001"的數據，T4時刻事務2取出了同一條數據，T5時刻事務1將age字段值更新為30，T6時刻事務2更新age為35并提交了數據，但是T7事務1回滾了事務age最后的值依然為20，事務2的更新丟失了，這種情況就叫做"第一類丟失更新(lost update)"。

2. 臟讀(dirty read)：如果第二個事務查詢到第一個事務還未提交的更新數據，形成臟讀。

?	事務1	事務2
1	開啟事務	?
2	?	開啟事務
3	取出數據 age=20	?
4	?	?
5	更新 age=30	?
6	?	讀取數據 age=30（臟讀）
7	?	?

?

在T1時刻開啟了事務1，T2時刻開啟了事務2，在T3時刻事務1從數據庫中取出了id="402881e535194b8f0135194b91310001"的數據，在T5時刻事務1將age的值更新為30，但是事務還未提交，T6時刻事務2讀取同一條記錄，獲得age的值為30，但是事務1還未提交，若在T7時刻事務1回滾了事務2的數據就是錯誤的數據(臟數據)，這種情況叫做" 臟讀(dirty read)"。

3. 虛讀(phantom read)：一個事務執行兩次查詢，第二次結果集包含第一次中沒有或者某些行已被刪除，造成兩次結果不一致，只是另一個事務在這兩次查詢中間插入或者刪除了數據造成的。

?	事務1	事務2
1	開啟事務	?
2	?	開啟事務
3	查詢數據，有一條記錄	?
4	?	插入一條記錄
5	?	?
6	?	提交事務
7	查詢數據，有2條記錄	?

?

在T1時刻開啟了事務1，T2時刻開啟了事務2，T3時刻事務1從數據庫中查詢所有記錄，記錄總共有一條，T4時刻事務2向數據庫中插入一條記錄，T6時刻事務2提交事務。T7事務1再次查詢數據數據時，記錄變成兩條了。這種情況是"虛讀(phantom read)"。

4. 不可重復讀(unrepeated read)：一個事務兩次讀取同一行數據，結果得到不同狀態結果，如中間正好另一個事務更新了該數據，兩次結果相異，不可信任。

?	事務1	事務2
1	開啟事務	?
2	?	開啟事務
3	查詢數據，age=20	?
4	?	查詢數據，age=20
5	?	更新數據，age=30
6	?	提交事務
7	查詢數據，age=30	?
8	?	?
9	?	?

?

在T1時刻開啟了事務1，T2時刻開啟了事務2，在T3時刻事務1從數據庫中取出了id="402881e535194b8f0135194b91310001"的數據，此時age=20，T4時刻事務2查詢同一條數據，T5事務2更新數據age=30，T6時刻事務2提交事務，T7事務1查詢同一條數據，發現數據與第一次不一致。這種情況就是"不可重復讀(unrepeated read)"。

5. 第二類丟失更新(second lost updates)：是不可重復讀的特殊情況，如果兩個事務都讀取同一行，然后兩個都進行寫操作，并提交，第一個事務所做的改變就會丟失。

?	事務1	事務2
1	開啟事務	?
2	?	開啟事務
3	更新數據，age=25	?
4	?	?
5	?	更新數據，age=30
6	提交事務	?
7	?	提交事務

?

在T1時刻開啟了事務1，T2時刻開啟了事務2，T3時刻事務1更新數據age=25，T5時刻事務2更新數據age=30，T6時刻提交事務，T7時刻事務2提交事務，把事務1的更新覆蓋了。這種情況就是"第二類丟失更新(second lost updates)"。

?

數據庫事務隔離級別

隔離級別	是否出現第一類丟失更新	是否出現臟讀	是否出現虛讀	是否出現不可重復讀	是否出現第二類丟失更新
Serializable	否	否	否	否	否
Repeatable Read	否	否	是	否	否
Read Commited	否	否	是	是	是
Read Uncommited	否	是	是	是	是

?

數據庫的事務隔離級別越高，越能解決并發中可能出現的問題。但是處理并發的能力就越弱。

也就是說，如果數據庫事務采用serializable級別的隔離級別，就不會發生并發的問題。但處理數據的能力非常弱。大部分數據庫都采用的是read commited隔離級別。

那怎么來解決并發中可能出現的問題呢?需要用到數據庫鎖。悲觀鎖和樂觀鎖。

悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個數據處理過程中，將數據處于鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）。

一個典型的悲觀鎖的調用：select * from users where name=’leo’ for update.

?	取款事務	存款事務
1	開始事務	?
2	?	開始事務
3	select * from accounts where id=1 for update; 查詢結果顯示存款余額為1000元，這條記錄被鎖定	?
4	?	select * from accounts where id=1 for update;執行該語句時，事務停下來等待取款事務解除對這條記錄的鎖定。
5	取出100元。把存款余額改為900元。	?
6	提交事務	?
7	?	事務回復運行，查詢結果顯示存款余額為900元。這條記錄被鎖定。
8	?	匯入100元，把存款余額改為1000元。
9	?	提交事務

?

使用樂觀鎖時，可以在表中添加一個字段：version。

但讀數據時，連同version一同讀出。在update時，將version+1，然后與數據庫中的version比較。如果大于數據庫中的版本，執行update。如果等于或小于數據庫中的version，那么就是臟數據。不執行。

數據庫事務