最近在看高性能MYSQL一書，所以對其進行例子分析已鞏固自己的印象

數據庫的事務操作其實就是一組原子性的操作，要么全部操作成功，要么全部操作失敗。

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

1.查詢電影票數量是否滿足銷售1張電影票S

ELECTremain_countFROMcinemaWHEREfilm_id=123456789; 

2.更新電影票數量

UPDATEremain_count=remain_count-1FROMcinemaWHEREfilm_id=123456789; 

3.插入銷售信息

INSERTINTOsell_mes(id,mes)values(id,mes); 

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

所以一個良好的系統是需要通過ACID測試，至于ACID是什么，就自行百度吧，這篇博文講的是隔離性的隔離級別以及例子

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

[[215804]]

1.READUNCIMMITTED（未提交讀）

事務中的修改，即使沒有提交，其他事務也可以看得到，比如說上面的兩步這種現象就叫做臟讀，這種隔離級別會引起很多問題，如無必要，不要隨便使用。

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

總結:這就是事務還沒提交，而別的事務可以看到他其中修改的數據的后果，也就是臟讀。

2.READCOMMITTED（提交讀）

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

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

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

3.REPEATABLEREAD（可重復讀）

REPEATABLEREAD解決了臟讀的問題，該級別保證了每行的記錄的結果是一致的，也就是上面說的讀了舊數據的問題，但是卻無法解決另一個問題，幻行，顧名思義就是突然蹦出來的行數據。指的就是某個事務在讀取某個范圍的數據，但是另一個事務又向這個范圍的數據去插入數據，導致多次讀取的時候，數據的行數不一致。

例子:銷售部門有規定，如果銷售記錄低于規定的值，要扣工資，此時經理在后端控制臺查看了一下小明的銷售記錄，發現銷售記錄達不到規定的次數，心里暗喜，準備打印好銷售清單，理直氣壯和小明提出，沒想到打印出來的時候發現銷售清單里面銷售數量增多了幾條，剛剛好達到要求，氣的經理撕了清單紙。原來是小明在就要打印的瞬間賣出了幾張票，因此避過了減工資的血光之災。

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

4.SERIALIZABLE（可串行化）

SERIALIZABLE是最高的隔離級別，它通過強制事務串行執行（注意是串行），避免了前面的幻讀情況，由于他大量加上鎖，導致大量的請求超時，因此性能會比較底下，再特別需要數據一致性且并發量不需要那么大的時候才可能考慮這個隔離級別。

分類:mysql