自然也是支援四種事務隔離級別的
read uncommitted，
read commit，
repeatable read
serializable，
下面就分別最四種隔離級別在實現的鎖機制做乙個簡介：
serializable：
1:這種隔離級別對資料的要求最為嚴格，自然也是效能最差的一種隔離級別。
在所有的select語句中都是預設加了乙個lock in share mode的鎖，
2：在這種隔離級別中沒有一致讀的，所有的select都將返回最近的資料狀態。
3：由於這種隔離級別的對資料高度一致的嚴格，所以會產生很多的鎖，自然也會導致很多的死鎖，對效能的影響不言而喻。
repeatable read：
1：所有的select在第一次一致讀以後在事務中都會使用一樣的資料狀態快照。
2：update，delete都會使用間隙鎖來保證資料的安全。防止phantom。
3：這是採用最廣的事務隔離級別，也是mysql預設的事務隔離級別。
read commited:
1:每乙個select都會使用各自的資料狀態的快照。
2:如果當前的資料狀態已更新到最新，但是噹噹個select的時候仍然會產生不一致的資料狀態。
3:更少的間隙鎖意味著更少的死鎖。
4:唯一key的檢查在第二索引和其它外來鍵檢查的時候也會產生間隙所。（gap必須被鎖定以防止在parent row被刪除後仍在child row中插入相關資料）。
5:這種隔離級別也是使用的非常普遍的隔離級別尤其是在5.1以後的版本中。
6：徵對在5.0更早的版本中，可以通過innodb_locks_unsafe_for_binlog移除gap locking。
（in v5.1, most gap-locking is removed w/ this level, but you must use row-based logging/replication。）
read uncommitted：
1：這種隔離級別幾乎不被使用，在selelct將會看到各種奇怪的資料現象，當然包括其它事務還未提交的資料。
2：強烈不推薦，不能保證資料的一致性。
事物隔離級別
隔離級別從松到緊 讀未提交，讀提交 重複讀，序列化。讀未提交 可能會出現髒讀的情況 例子 你去買5個包子。人多。店員拿的急多方乙個，袋子裡有6個，這個時候，你眼睛一瞟。心裡美滋滋。付錢的時候老闆檢查了一下，發現多了乙個，就拿走了乙個，然後你付錢走人 提交事務 這時候你就發現實際上袋子裡只有5個，但是...
事物隔離級別
在分布式的系統中，通常會有多個執行緒連線到資料庫中同時對乙個表進行操作 這裡的同時並不表示同乙個時間點，而是同時競爭cpu的資源，至於如何排程，就要看執行緒和作業系統如何進行排程了 這種情況下如果會話的事物設定不當，就會導致資料混亂，常常會出現以下三種情況 假設現在系統中有兩個會話a和b，同時對錶t...
事物隔離級別
事務隔離級別 1.更新遺失 lost update 兩個事務都同時更新一行資料，但是第二個事務卻中途失敗退出，導致對資料的兩個修改都失效了。這是因為系統沒有執行任何的鎖操作，因此併發事務並沒有被隔離開來。基本上就是指某個事務對欄位進行更新的資訊，因另乙個事務的介入而遺失更新效力。舉例來說，若某個字段...