髒讀（Dirty Read)
髒讀意味着一個事務讀取了另一個事務未提交的數據,而這個數據是有可能回滾
不可重複讀(Unrepeatable Read)
不可重複讀意味着，在數據庫訪問中，一個事務範圍內兩個相同的查詢卻返回了不同數據。這是由於查詢時系統中其他事務修改的提交而引起的。
例如：事務B中對某個查詢執行兩次，當第一次執行完時，事務A對其數據進行了修改。事務B中再次查詢時，數據發生了改變
幻讀(phantom read)
幻讀,是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的數據進行了修改，這種修改涉及到表中的全部數據行。同時，第二個事務也修改這個表中的數據，這種修改是向表中插入一行新數據。那麼，以後就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行，就好象發生了幻覺一樣.
下面是轉載，原文地址：http://singo107.iteye.com/blog/1175084
數據庫事務的隔離級別有4個，由低到高依次爲Read uncommitted、Read committed、Repeatable read、Serializable，這四個級別可以逐個解決髒讀、不可重複讀、幻讀這幾類問題。
√: 可能出現 ×: 不會出現
| 髒讀 | 不可重複讀 | 幻讀 | |
| Read uncommitted | √ | √ | √ |
| Read committed | × | √ | √ |
| Repeatable read | × | × | √ |
| Serializable | × | × | × |
注意：我們討論隔離級別的場景，主要是在多個事務併發的情況下，因此，接下來的講解都圍繞事務併發。
Read uncommitted 讀未提交
公司發工資了，領導把5000元打到singo的賬號上，但是該事務並未提交，而singo正好去查看賬戶，發現工資已經到賬，是5000元整，非常高興。可是不幸的是，領導發現發給singo的工資金額不對，是2000元，於是迅速回滾了事務，修改金額後，將事務提交，最後singo實際的工資只有2000元，singo空歡喜一場。
出現上述情況，即我們所說的髒讀，兩個併發的事務，“事務A：領導給singo發工資”、“事務B：singo查詢工資賬戶”，事務B讀取了事務A尚未提交的數據。
當隔離級別設置爲Read uncommitted時，就可能出現髒讀，如何避免髒讀，請看下一個隔離級別。
Read committed 讀提交
singo拿着工資卡去消費，系統讀取到卡里確實有2000元，而此時她的老婆也正好在網上轉賬，把singo工資卡的2000元轉到另一賬戶，並在singo之前提交了事務，當singo扣款時，系統檢查到singo的工資卡已經沒有錢，扣款失敗，singo十分納悶，明明卡里有錢，爲何......
出現上述情況，即我們所說的不可重複讀，兩個併發的事務，“事務A：singo消費”、“事務B：singo的老婆網上轉賬”，事務A事先讀取了數據，事務B緊接了更新了數據，並提交了事務，而事務A再次讀取該數據時，數據已經發生了改變。
當隔離級別設置爲Read committed時，避免了髒讀，但是可能會造成不可重複讀。
大多數數據庫的默認級別就是Read committed，比如Sql Server , Oracle。如何解決不可重複讀這一問題，請看下一個隔離級別。
Repeatable read 重複讀
當隔離級別設置爲Repeatable read時，可以避免不可重複讀。當singo拿着工資卡去消費時，一旦系統開始讀取工資卡信息（即事務開始），singo的老婆就不可能對該記錄進行修改，也就是singo的老婆不能在此時轉賬。
雖然Repeatable read避免了不可重複讀，但還有可能出現幻讀。
singo的老婆工作在銀行部門，她時常通過銀行內部系統查看singo的信用卡消費記錄。有一天，她正在查詢到singo當月信用卡的總消費金額（select sum(amount) from transaction where month = 本月）爲80元，而singo此時正好在外面胡吃海塞後在收銀臺買單，消費1000元，即新增了一條1000元的消費記錄（insert transaction ... ），並提交了事務，隨後singo的老婆將singo當月信用卡消費的明細打印到A4紙上，卻發現消費總額爲1080元，singo的老婆很詫異，以爲出現了幻覺，幻讀就這樣產生了。
注：Mysql的默認隔離級別就是Repeatable read。
Serializable 序列化
Serializable是最高的事務隔離級別，同時代價也花費最高，性能很低，一般很少使用，在該級別下，事務順序執行，不僅可以避免髒讀、不可重複讀，還避免了幻像讀。