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

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

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

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

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

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

延伸閱讀：

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

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

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

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

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

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

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

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