{首页主词},&

一、為什么MySQL在innodb引擎中即使使用了MVCC機(jī)制仍然會(huì)出現(xiàn)丟失更新

mvcc在innodb中只負(fù)責(zé)解決讀寫沖突，把普通select語句變成快照讀。寫沖突仍然是靠鎖來解決的。因此要解決你說的丟失更新，要用select…for update主動(dòng)加x鎖。

當(dāng)然mvcc不是說完全不能解決丟失更新，比如postgresql的serializable隔離級(jí)別下，遇到寫寫沖突直接向客戶端返回異常，保證只有一個(gè)事務(wù)可以更新成功。

Mysql在可重復(fù)讀隔離級(jí)別下可保證事務(wù)較高的隔離性，同樣的sql查詢語句在一個(gè)事務(wù)里多次執(zhí)行查詢結(jié)果相同，就算其它事務(wù)對(duì)數(shù)據(jù)有修改也不會(huì)影響當(dāng)前事務(wù)sql語句的查詢結(jié)果

?? 這個(gè)隔離性就是靠MVCC(Multi-Version Concurrency Control)機(jī)制保證

對(duì)一行數(shù)據(jù)的讀和寫兩個(gè)操作默認(rèn)是不會(huì)通過加鎖互斥來保證隔離性，避免了頻繁加鎖互斥而在串行化隔離級(jí)別為了保證較高的隔離性是通過將所有操作加鎖互斥來實(shí)現(xiàn)的

延伸閱讀：

二、MVCC多版本并發(fā)控制機(jī)制的實(shí)現(xiàn)

undo日志版本鏈?zhǔn)侵敢恍袛?shù)據(jù)被多個(gè)事務(wù)依次修改過后，在每個(gè)事務(wù)修改完后，Mysql會(huì)保留修改前的數(shù)據(jù)undo回滾日志，并且用兩個(gè)隱藏字段trx_id和roll_pointer把這些undo日志串聯(lián)起來形成一個(gè)歷史記錄版本鏈。

在可重復(fù)讀隔離級(jí)別，當(dāng)事務(wù)開啟，執(zhí)行任何查詢sql時(shí)會(huì)生成當(dāng)前事務(wù)的一致性視圖read-view該視圖在事務(wù)結(jié)束之前都不會(huì)變化(如果是讀已提交隔離級(jí)別在每次執(zhí)行查詢sql時(shí)都會(huì)重新生成)該視圖由執(zhí)行查詢時(shí)所有未提交事務(wù)id數(shù)組（數(shù)組里最小的id為min_id）和已創(chuàng)建的最大事務(wù)id（max_id）組成事務(wù)里任何sql的查詢結(jié)果需要從對(duì)應(yīng)版本鏈里的最新數(shù)據(jù)開始逐條跟read-view做比對(duì)從而得到最終的快照結(jié)果

1.如果 row 的 trx_id 落在綠色部分( trx_id

2. 如果 row 的 trx_id 落在紅色部分( trx_id>max_id )，表示這個(gè)版本是由將來啟動(dòng)的事務(wù)生成的，是不可見的(若 row 的 trx_id 就是當(dāng)前自己的事務(wù)是可見的）；

3. 如果 row 的 trx_id 落在黃色部分(min_id <=trx_id<= max_id)，那就包括兩種情況：

若 row 的 trx_id 在視圖數(shù)組中，表示這個(gè)版本是由還沒提交的事務(wù)生成的，不可見(若 row 的 trx_id 就是當(dāng)前自己的事務(wù)，是可見的)；

若 row 的 trx_id 不在視圖數(shù)組中，表示這個(gè)版本是已經(jīng)提交了的事務(wù)生成的，可見。

為什么MySQL在innodb引擎中即使使用了MVCC機(jī)制仍然會(huì)出現(xiàn)丟失更新?