一般的資料庫，都包括以下四種隔離級別： 讀未提交（Read Uncommitted） 在這種隔離級別下，查詢是不會加鎖的，也由於查詢的不加鎖， 所以這種隔離級別的一致性是最差的，可能會產生“髒讀”、“不可重複讀”、“幻讀”。 讀提交（Read Committed） 讀提交，顧名思義，就是隻能讀到已經提交了的內容。 這是各種系統中最常用的一種隔離級別，也是SQL Server和Oracle的預設隔離級別。 這種隔離級別能夠有效的避免髒讀，但除非在查詢中顯示的加鎖， 不然，普通的查詢是不會加鎖的。 那為什麼“讀提交”同“讀未提交”一樣，都沒有查詢加鎖，但是卻能夠避免髒讀呢？、 這就要說道另一個機制“快照（snapshot）”， 而這種既能保證一致性又不加鎖的讀也被稱為“快照讀（Snapshot Read）” 假設沒有“快照讀”，那麼當一個更新的事務沒有提交時， 另一個對更新資料進行查詢的事務會因為無法查詢而被阻塞， 這種情況下，併發能力就相當的差。 而“快照讀”就可以完成高併發的查詢，不過， “讀提交”只能避免“髒讀”，並不能避免“不可重複讀”和“幻讀”。

可重複讀（Repeated Read） 可重複讀，顧名思義，就是專門針對“不可重複讀”這種情況而制定的隔離級別， 自然，它就可以有效的避免“不可重複讀”。而它也是MySql的預設隔離級別。 在這個級別下，普通的查詢同樣是使用的“快照讀”， 但是，和“讀提交”不同的是，當事務啟動時，就不允許進行“修改操作（Update）”了， 而“不可重複讀”恰恰是因為兩次讀取之間進行了資料的修改， 因此，“可重複讀”能夠有效的避免“不可重複讀”，但卻避免不了“幻讀”， 因為幻讀是由於“插入或者刪除操作（Insert or Delete）”而產生的。

序列化讀（Serializable） 這是資料庫最高的隔離級別，這種級別下，事務“序列化順序執行”，也就是一個一個排隊執行。 這種級別下，“髒讀”、“不可重複讀”、“幻讀”都可以被避免， 但是執行效率奇差，效能開銷也最大，所以基本沒人會用。 總結一下 為什麼會出現“髒讀”？因為沒有“select”操作沒有規矩。 為什麼會出現“不可重複讀”？因為“update”操作沒有規矩。 為什麼會出現“幻讀”？因為“insert”和“delete”操作沒有規矩。 “讀未提（Read Uncommitted）”能預防啥？啥都預防不了。 “讀提交（Read Committed）”能預防啥？ 使用“快照讀（Snapshot Read）”，避免“髒讀”，但是可能出現“不可重複讀”和“幻讀”。 “可重複讀（Repeated Red）”能預防啥？ 使用“快照讀（Snapshot Read）”，鎖住被讀取記錄， 避免出現“髒讀”、“不可重複讀”，但是可能出現“幻讀”。 “序列化（Serializable）”能預防啥？ 排排坐，吃果果，有效避免“髒讀”、“不可重複讀”、“幻讀”，不過效果誰用誰知道