mysql事務隔離級別和MVCC

一、三種問題：

臟讀(Drity Read)：事務A更新記錄但未提交，事務B查詢出A未提交記錄。

不可重復讀(Non-repeatable read):在一個事務的兩次查詢之中數據不一致，這可能是兩次查詢過程中間插入了一個事務更新的原有的數據。

幻讀(Phantom Read):在一個事務的兩次查詢中數據筆數不一致，例如有一個事務查詢了幾行數據，而另一個事務卻在此時插入了幾行數據，先前的事務在接下來的查詢中，就會發現有幾行數據是它先前所沒有的。

 

二、四種隔離級別

Read Uncommitted（讀取未提交內容）：可能讀取其它事務未提交的數據。不能避免：臟讀+不可重復讀+幻讀

Read Committed（讀取提交內容）：一個事務只能看見已經提交事務所做的改變。但同一事務的其他實例在該實例處理其間可能會有新的commit，所以同一select可能返回不同結果。不能避免：不可重復讀+幻讀

Repeatable Read（可重讀）：它確保同一事務的多個實例在並發讀取數據時，會看到同樣的數據行。不能避免：幻讀

Serializable（可串行化）：這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數據行上加上共享鎖。在這個級別，可能導致大量的超時現象和鎖競爭。

 

三、mysql默認隔離級別？

文檔上寫的都是：Repeatable Read，也就是說可能會出現幻讀。但是注意innodb引擎下不存在幻讀！

MySQL InnoDB存儲引擎，實現的是基於多版本的並發控制協議——MVCC (Multi-Version Concurrency Control) 在Repeatable Read (RR)隔離級別下不存在幻讀。

1.普通MVCC：

• 每行數據都存在一個版本，每次數據更新時都更新該版本
• 修改時Copy出當前版本隨意修改，各個事務之間無干擾
• 保存時比較版本號，如果成功（commit），則覆蓋原記錄；失敗則放棄copy（rollback）

就是每行都有版本號，保存時根據版本號決定是否成功，聽起來含有 樂觀鎖的味道

2. Innodb的實現方式是：

• 事務以排他鎖的形式修改原始數據
• 把修改前的數據存放於undo log，通過回滾指針與主數據關聯
• 修改成功（commit）啥都不做，失敗則恢復undo log中的數據（rollback）

二者最本質的區別是，當修改數據時是否要排他鎖定，如果鎖定了還算不算是MVCC？ 

 

讀鎖：也叫共享鎖、S鎖，若事務T對數據對象A加上S鎖，則事務T可以讀A但不能修改A，其他事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S 鎖。這保證了其他事務可以讀A，但在T釋放A上的S鎖之前不能對A做任何修改。

寫鎖：又稱排他鎖、X鎖。若事務T對數據對象A加上X鎖，事務T可以讀A也可以修改A，其他事務不能再對A加任何鎖，直到T釋放A上的鎖。這保證了其他事務在T釋放A上的鎖之前不能再讀取和修改A。

表鎖：操作對象是數據表。Mysql大多數鎖策略都支持(常見mysql innodb)，是系統開銷最低但並發性最低的一個鎖策略。事務t對整個表加讀鎖，則其他事務可讀不可寫，若加寫鎖，則其他事務增刪改都不行。

行級鎖：操作對象是數據表中的一行。是MVCC技術用的比較多的，但在MYISAM用不了，行級鎖用mysql的儲存引擎實現而不是mysql服務器。但行級鎖對系統開銷較大，處理高並發較好。

 

總結：

Innodb的實現真算不上MVCC，因為並沒有實現核心的多版本共存，undo log中的內容只是串行化的結果，記錄了多個事務的過程，不屬於多版本共存。但理想的MVCC是難以實現的，當事務僅修改一行記錄使用理想的MVCC模式是沒有問題的，可以通過比較版本號進行回滾；但當事務影響到多行數據時，理想的MVCC據無能為力了。理想MVCC難以實現的根本原因在於企圖通過樂觀鎖代替二段提交。修改兩行數據，但為了保證其一致性，與修改兩個分布式系統中的數據並無區別，而二段提交是目前這種場景保證一致性的唯一手段。二段提交的本質是鎖定，樂觀鎖的本質是消除鎖定，二者矛盾。

二段提交：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。