为什么MySQL在innodb引擎中即使使用了MVCC机制仍然会出现丢失更新

mvcc在innodb中只负责解决读写冲突，把普通select语句变成快照读。写冲突仍然是靠锁来解决的。因此要解决你说的丢失更新，要用select…for update主动加x锁。当然mvcc不是说完全不能解决丢失更新，比如postgresql的serializable隔离级别下。

一、为什么MySQL在innodb引擎中即使使用了MVCC机制仍然会出现丢失更新

mvcc在innodb中只负责解决读写冲突，把普通select语句变成快照读。写冲突仍然是靠锁来解决的。因此要解决你说的丢失更新，要用select…for update主动加x锁。

当然mvcc不是说完全不能解决丢失更新，比如postgresql的serializable隔离级别下，遇到写写冲突直接向客户端返回异常，保证只有一个事务可以更新成功。

Mysql在可重复读隔离级别下可保证事务较高的隔离性，同样的sql查询语句在一个事务里多次执行查询结果相同，就算其它事务对数据有修改也不会影响当前事务sql语句的查询结果

 这个隔离性就是靠MVCC(Multi-Version Concurrency Control)机制保证

延伸阅读：

undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链。

在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view
该视图在事务结束之前都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成)
该视图由执行查询时所有未提交事务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成
- 事务里任何sql的查询结果需要从对应版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果

1.如果 row 的 trx_id 落在绿色部分( trx_id<min_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；

2. 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的）；

3. 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况：

若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自己的事务，是可见的)；

若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。