事務的隔離級別

四種隔離級別

• read uncommitted   ：讀未提交　　　——— 引起問題 ———> 　 　　　　　　　　　　　 隱患：髒讀

• read committed　　：讀已提交　　    ——— 引起問題 ———>　　解決髒讀隱患 　　　　 隱患：不可重複讀

• repeatable read　　：可重複讀　　　——— 引起問題 ———>　　解決髒讀、不可重複讀，隱患：幻讀

• serializable　　　　：可串行化　　　——— 引起問題 ———>　　解決以上全部隱患　　　隱患：影響性能，效率過低

髒讀、幻讀、不可重複讀：

• 髒讀：A事務讀取可B事務還沒有提交的數據，若是B事務在A事務讀取了還沒有提交的數據後再次改了數據後提交 就會形成A事務的數據所有錯誤

• 不可重複讀：A事務對某一數據進行讀取後，進行其餘的操做 ，此時B事務對該數據進行了修改並提交 ，A事務想校驗該數據的真實性，再次讀取該數據形成先後兩次讀取數據的內容的不一樣　（側重點在於內容的不一致）

• 幻讀/虛讀：　A事務對某一數據進行讀取後，進行其餘的操做 ，此時B事務對該數據進行了增/刪 並提交 ，A事務想校驗該數據的真實性，再次讀取該數據形成先後兩次讀取數據的數量的不一樣　（側重點在於數量的不一致）

關於丟失數據隱患的理解：

• A，B事務同時對一組數據進行操做， A事務操做完以後數據提交， B事務操做後不管是提交仍是回滾 都會使A事務提交的數據無效，形成更新丟失隱患

• 解決方案：

• 樂觀鎖：(歷來不以爲會發生更新丟失隱患) 要求在表中額外添加一個字段（假設 versionv int ）默認爲0，當A事務對其數據進行修改後，要對其+1操做，第二個事務想執行修改的時候，先查 version是否爲先前查到的值，若是不是從新查詢得到數據再修改提交

• 悲觀鎖：(認爲更新丟失確定會發生，採用霸王手段隔絕) 在查詢時 手動添加 排它鎖 select * from xxx for update 能夠理解爲兩我的想喝水，只有一個杯子，先拿到杯子的先喝，喝完纔會把杯子使用權交出來，後面其餘事物想操做這個表，所有處於等待狀態

讀取多：使用樂觀鎖，提升吞吐量

修改多：使用悲觀鎖