read uncommit, read commit, repeatable read, 共享鎖VS排他鎖
阿新 • • 發佈：2018-11-13
一般大家都對事務的四種隔離模式比較熟悉，從鬆到嚴依次是：
- 讀取未提交(Read uncommitted)：處於此模式下可能會出現髒讀、幻象讀、不可重複讀
- 讀取已提交(Read committed)：處於此模式下可能會出現幻象讀、不可重複讀
- 可重複讀(Repeatable read)：處於此模式下可能會出現幻象讀
- 序列(Serialize)：不會出現幻象讀
那麼髒讀、幻象行、不可重複讀是什麼意思呢？
- 髒讀：其它的事務（執行單個 select 語句也算一個事務）可以讀取到某個事務更新（包括插入和刪除）了但未提交的資料。髒讀是應用中應該避免的，因為讀取的是不可靠的資料（我覺得把這個叫做幻象行更形象，實際卻不是）。一般資料庫不會設定為這個模式，但有時候也會用到。髒讀的好處是讀取時不會對錶或記錄加鎖，可以繞開寫佇列的排隊，避免了等待。如在一個更新特別頻繁的表中要選擇表中所有的資料，就可以顯示指定隔離級別：
------------------------------------- 資料庫中事務的 ACID 原則 原子性 (Atomicity)： 事務的原子性是指一個事務中包含的一條語句或者多條語句構成了一個完整的邏輯單元，這個邏輯單元具有不可再分的原子性。這個邏輯單元要麼一起提交執行全部成功，要麼一起提交執行全部失敗。 一致性 (Consistency)： 可以理解為資料的完整性，事務的提交要確保在資料庫上的操作沒有破壞資料的完整性，比如說不要違背一些約束的資料插入或者修改行為。一旦破壞了資料的完整性，SQL Server 會回滾這個事務來確保資料庫中的資料是一致的。 隔離性(Isolation)： 與資料庫中的事務隔離級別以及鎖相關，多個使用者可以對同一資料併發訪問而又不破壞資料的正確性和完整性。但是，並行事務的修改必須與其它並行事務的修改相互獨立，隔離。 但是在不同的隔離級別下，事務的讀取操作可能得到的結果是不同的。 永續性(Durability)： 資料持久化，事務一旦對資料的操作完成並提交後，資料修改就已經完成，即使服務重啟這些資料也不會改變。相反，如果在事務的執行過程中，系統服務崩潰或者重啟，那麼事務所有的操作就會被回滾，即回到事務操作之前的狀態。 我理解在極端斷電或者系統崩潰的情況下，一個發生在事務未提交之前，資料庫應該記錄了這個事務的"ID"和部分已經在資料庫上更新的資料。供電恢復資料庫重新啟動之後，這時完成全部撤銷和回滾操作。如果在事務提交之後的斷電，有可能更改的結果沒有正常寫入磁碟持久化，但是有可能丟失的資料會通過事務日誌自動恢復並重新生成以寫入磁碟完成持久化。
---------------------------------- 共享鎖【S鎖】 又稱讀鎖，若事務T對資料物件A加上S鎖，則事務T可以讀A但不能修改A，其他事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S鎖。這保證了其他事務可以讀A，但在T釋放A上的S鎖之前不能對A做任何修改。 排他鎖【X鎖】 又稱寫鎖。若事務T對資料物件A加上X鎖，事務T可以讀A也可以修改A，其他事務不能再對A加任何鎖，直到T釋放A上的鎖。這保證了其他事務在T釋放A上的鎖之前不能再讀取和修改A。
---------------------------------- 總結：隔離模式(isolation)其實就是對讀寫加鎖的形象稱謂，應用在每個具體事務上。對資料庫本身而言，只有鎖的概念並沒有隔離模式的概念。當資料庫發現某個物件被加上共享鎖時，其他修改該物件的操作就被阻塞，直到該物件上的所有共享鎖都被釋放為止。
------------------------------------- 資料庫中事務的 ACID 原則 原子性 (Atomicity)： 事務的原子性是指一個事務中包含的一條語句或者多條語句構成了一個完整的邏輯單元，這個邏輯單元具有不可再分的原子性。這個邏輯單元要麼一起提交執行全部成功，要麼一起提交執行全部失敗。 一致性 (Consistency)： 可以理解為資料的完整性，事務的提交要確保在資料庫上的操作沒有破壞資料的完整性，比如說不要違背一些約束的資料插入或者修改行為。一旦破壞了資料的完整性，SQL Server 會回滾這個事務來確保資料庫中的資料是一致的。 隔離性(Isolation)： 與資料庫中的事務隔離級別以及鎖相關，多個使用者可以對同一資料併發訪問而又不破壞資料的正確性和完整性。但是，並行事務的修改必須與其它並行事務的修改相互獨立，隔離。 但是在不同的隔離級別下，事務的讀取操作可能得到的結果是不同的。 永續性(Durability)： 資料持久化，事務一旦對資料的操作完成並提交後，資料修改就已經完成，即使服務重啟這些資料也不會改變。相反，如果在事務的執行過程中，系統服務崩潰或者重啟，那麼事務所有的操作就會被回滾，即回到事務操作之前的狀態。 我理解在極端斷電或者系統崩潰的情況下，一個發生在事務未提交之前，資料庫應該記錄了這個事務的"ID"和部分已經在資料庫上更新的資料。供電恢復資料庫重新啟動之後，這時完成全部撤銷和回滾操作。如果在事務提交之後的斷電，有可能更改的結果沒有正常寫入磁碟持久化，但是有可能丟失的資料會通過事務日誌自動恢復並重新生成以寫入磁碟完成持久化。
---------------------------------- 共享鎖【S鎖】 又稱讀鎖，若事務T對資料物件A加上S鎖，則事務T可以讀A但不能修改A，其他事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S鎖。這保證了其他事務可以讀A，但在T釋放A上的S鎖之前不能對A做任何修改。 排他鎖【X鎖】 又稱寫鎖。若事務T對資料物件A加上X鎖，事務T可以讀A也可以修改A，其他事務不能再對A加任何鎖，直到T釋放A上的鎖。這保證了其他事務在T釋放A上的鎖之前不能再讀取和修改A。
---------------------------------- 總結：隔離模式(isolation)其實就是對讀寫加鎖的形象稱謂，應用在每個具體事務上。對資料庫本身而言，只有鎖的概念並沒有隔離模式的概念。當資料庫發現某個物件被加上共享鎖時，其他修改該物件的操作就被阻塞，直到該物件上的所有共享鎖都被釋放為止。