最近在看高性能MYSQL一書，所以對其進行例子分析已鞏固自己的印象 資料庫的事務操作其實就是一組原子性的操作，要麼全部操作成功，要麼全部操作失敗。 比如說我需要對外銷售1張電影票，且登記一下銷售信息到另一個表，至少需要以下3個步驟 1.查詢電影票數量是否滿足銷售1張電影票 SELECT remain ...
最近在看高性能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是最高的隔離級別，它通過強制事務串列執行（註意是串列），避免了前面的幻讀情況，由於他大量加上鎖，導致大量的請求超時，因此性能會比較底下，再特別需要數據一致性且併發量不需要那麼大的時候才可能考慮這個隔離級別
