數據庫的四種隔離級別

　　最近在看高性能MYSQL一書，因此對其進行例子分析已鞏固本身的印象

　　數據庫的事務操做其實就是一組原子性的操做，要麼所有操做成功，要麼所有操做失敗。

　　

　　好比說我須要對外銷售1張電影票，且登記一下銷售信息到另外一個表，至少須要如下3個步驟

　　1.查詢電影票數量是否知足銷售1張電影票 SELECT remain_count FROM cinema WHERE film_id = 123456789;

　　2.更新電影票數量 UPDATE remain_count = remain_count -1 FROM cinema WHERE film_id=123456789;

　　3.插入銷售信息   INSERT  INTO sell_mes(id ,mes) values(id,mes);

　　試想一下若是咱們其中的一步被出錯了或者被其餘操做打亂就很容易出現問題。好比說有兩個銷售系統A,B在銷售一樣的票，此時票只剩下1張，A接到訂單要售出一張票，他查看電影票的數量大於1，因而要售出的時候，也就是在第一步執行完畢執行第二步的時候，B也接到訂單，也看到餘票大於1，B也要售出1張票。此時就出現了餘票只有1張卻售出兩張的荒唐的狀況出現。

　　因此一個良好的系統是須要經過ACID測試，至於ACID是什麼，就自行百度吧，這篇博文講的是隔離性的隔離級別以及例子

　　而事務的隔離級別有四種，隔離級別高的數據庫的可靠性高，但併發量低，而隔離級別低的數據庫可靠性低，但併發量高，系統開銷小

　　

　　1.READ UNCIMMITTED（未提交讀）

　　事務中的修改，即便沒有提交，其餘事務也能夠看獲得，好比說上面的兩步這種現象就叫作髒讀，這種隔離級別會引發不少問題，如無必要，不要隨便使用

　　例子:仍是售票系統，小明和小花是售票員，他們分別是兩個不一樣窗口的員工，如今售票系統只剩下3張票，此時A來小華這裏買3張票，B來小明買票，小華查到餘票還有就給接了訂單，就要執行第三步的時候，小明接到B的請求查詢有沒有餘票。看到小華賣出了3張票，因而拒絕賣票。可是小華系統出了問題，第三步執行失敗，數據庫爲保證原子性，數據進行了回滾，也就是說一張票都沒賣出去。

　　總結:這就是事務還沒提交，而別的事務能夠看到他其中修改的數據的後果，也就是髒讀。

　　

　　2.READ COMMITTED（提交讀）

　　大多數數據庫系統的默認隔離級別是READ COMMITTED，這種隔離級別就是一個事務的開始，只能看到已經完成的事務的結果，正在執行的，是沒法被其餘事務看到的。這種級別會出現讀取舊數據的現象

　　例子:仍是小明小華銷售員，餘票3張，A來小華那裏請求3張訂票單，小華接受訂單，要賣出3張票，上面的銷售步驟執行中的時候，B也來小明那裏買票，因爲小華的銷售事務執行到一半，小明事務沒有看到小華的事務執行，讀到的票數是3，準備接受訂單的時候，小華的銷售事務完成了，此時小明的系統變成顯示0張票，小明剛想按下鼠標點擊接受訂單的手又連忙縮了回去。

　　總結:這就是小華的事務執行到一半，而小明看不到他執行的操做，因此看到的是舊數據，也就是無效的數據

 

　　3.REPEATABLE READ（可重複讀）

 　　REPEATABLE READ解決了髒讀的問題，該級別保證了每行的記錄的結果是一致的，也就是上面說的讀了舊數據的問題，可是卻沒法解決另外一個問題，幻行，顧名思義就是忽然蹦出來的行數據。指的就是某個事務在讀取某個範圍的數據，可是另外一個事務又向這個範圍的數據去插入數據，致使屢次讀取的時候，數據的行數不一致。

　　例子:銷售部門有規定，若是銷售記錄低於規定的值，要扣工資，此時經理在後端控制檯查看了一下小明的銷售記錄，發現銷售記錄達不到規定的次數，內心暗喜，準備打印好銷售清單，義正詞嚴和小明提出，沒想到打印出來的時候發現銷售清單裏面銷售數量增多了幾條，剛恰好達到要求，氣的經理撕了清單紙。原來是小明在就要打印的瞬間賣出了幾張票，所以避過了減工資的血光之災。

　　總結:雖然讀取同一條數據能夠保證一致性，可是卻不能保證沒有插入新的數據

 

　　4.SERIALIZABLE（可串行化）

　　SERIALIZABLE是最高的隔離級別，它經過強制事務串行執行（注意是串行），避免了前面的幻讀狀況，因爲他大量加上鎖，致使大量的請求超時，所以性能會比較底下，再特別須要數據一致性且併發量不須要那麼大的時候纔可能考慮這個隔離級別