MVCC、事务以及事务的隔离级别

事务隔离级别：

未提交读（Read UnCommitted）：最不安全的隔离方式，一个事务可以读到另一个事务未提交的数据。另一个事务存在回滚的情况。

提交读（Read Committed）：一个事务提交之后，它作出的改变才能够被别的事务看到。

可重复读（Repetable Read）：一个事务读可以读取到其他事务提交的数据，但是在RR隔离级别下，当前读取此条数据只可读取一次，在当前事务中，不论读取多少次，数据仍然是第一次读取的值，不会因为在第一次读取之后，其他事务再修改提交此数据而产生改变。

序列化（Serializable）：对于同一个记录来说，写会加写锁，读也会加读锁，当出现读写锁冲突的时候，后一个事务必须等待前一个事务完成再进行。（隔离级别的黄金档）

并发控制产生的问题：

• 丢失修改：两个事务T1和T2同时读取一个数据并修改，T2提交的结果破坏T1提交的结果。
• 不可重复读：事务T1进行读取数据，T2进行修改数据（后两者可称幻影）
  • T1先读数据，T2进行修改，T1再次进行读取数据发现数据不一致；
  • T1先读数据，T2进行数据删除，T1再次进行读取数据发现少了某些数据；
  • T1先读数据，T2进行数据添加，T1再次进行读取数据发现多了某些数据；
• 脏读：T1进行数据读取且修改，T2进行读取，然后T1因为种种原因进行回滚数据，然后T2读的数据就和数据库的数据不一致。

LBCC解决数据丢失问题：基于锁的并发控制

​ 基于锁的形式，当事务要进行数据修改时，当前事务加上锁，同一时间仅仅允许一个事务操作，其他事物需等待释放锁。

MVCC解决数据丢失问题：多版本的并发控制

​ 使用版本来控制并发情况下数据问题，比如在事务1对数据修改且还未提交事务，事务2需要读取数据时，事务2会读取到事务1操作之前的数据副本，但是如果事务2需要进行数据修改就必须等待事务1提交事务才可以进行修改数据。

​ MVCC使数据库不会对数据加锁，普通的select请求不会加锁，提高数据库的并发处理能力。

通用的InnoDb的MVCC实现逻辑：

InnoDB的MVCC是通过在每行记录后面保存了两个影藏的列来实现的；一个是保存了行的事务ID（DB-TRX-ID），一行保存了行的回滚指针（DB-ROLL-RT）。每一个新开始的事务都会有一个自增的新的事务id。当事务开始执行时，会将这个事务新生成的id放到当前事务影响的行事务id中，查询时进行与每行的事务ID进行比较。

在RR级别总会得到数据库最新的数据、序列化所有的请求都会加锁所以这两个级别就不需要使用ReadView的版本控制。

通俗的说MVCC就是在事务隔离级别为Read Committed、Repeatable Committed的事务在执行select操作时访问记录的版本链的过程；可以使不同的事务读写、写读操作并发执行，从而提高性能。

而且在Mysql中，读提交和重复读隔离级别最大的区别就是他们产生的ReadView不同，读提交的情况下每次查询都会产生一个实时的ReadView，保证每次提交是处于当前的可见状态；重复读是事务第一次查询时产生，而且会一直用到提交事务，以此来保证可重复读的安全性。

事务：

简单的说就是一组操作要不全部执行要不就是不执行，绝对不允许产生部分执行的情况；

​ 再有就是事务的回滚Rollback，一次事务出现异常的情况进行插销已经做出的操作；

​ 事务提交，一般是进行关闭自动提交事务，而进行完操作来手动提交事务。

原子性：事务的最小单元，要么全部成功，要么全部失败；

一致性：事务开始和事务结束后，数据库的完整性不会被破坏；

隔离性：不同的事务之间互不影响；

持久性：事务提交后，对数据的修改时永久性的，即使系统发生问题也不会丢失。