【快速回顾】
MVCC以非阻塞的方式解决多事务读写冲突（实现事务隔离级别RC、RR）的问题，
锁机制解决多事务写写冲突和幻读的问题。
锁的分类：
- 按照对数据操作的类型来分，分为读锁和写锁。
- 按照锁的粒度来分，可分为行锁（间隙锁、临键锁、记录锁）、表锁（意向锁、自增锁）、页锁。
- 按照锁的意识形态分，又有悲观锁和乐观锁。悲观锁对应的实现有共享锁（又称读锁，简称S锁）和排他锁(又称写锁，简称X锁)，Java中的synchronized关键字；乐观锁对应的实现java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现、还有就是通过版本号控制。
读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会互相影响。
写锁（排它锁）：当前写操作没有完成前，它会阻断其他的写锁和读锁。
MySQL事务，ACID，即原子性、一致性、隔离性、持久性。它们分别对应的实现原理？？？
锁机制和MVCC是为了解决多个连接或者多个事务并发访问的情况。其中MVCC以非阻塞的方式解决多事务读写冲突（事务隔离级别RR）的问题，锁机制解决多事务写写冲突和幻读的问题。
事务的隔离性分四种，读未提交，读已提交，可重复读，串行化。其中读未提交相当于没有事务控制，串行化其实就是加表锁，那么重点就是读已提交(RC)和可重复读(RR)。RC隔离级别可解决脏读问题，RR隔离级别解决不可重复读的问题。
大多数数据库默认的事务隔离级别是Read Committed，比如Sql Server , Oracle。Mysql的默认隔离级别是Repeatable Read。
隔离级别（读写问题）
读未提交（未加锁）：
? ? ? ?事务A读取数据的时候允许事务B修改，并且不用等事务B提交（commit）就可读到修改后的数据。这会存在脏读的问题。
读已提交（未加锁）：
? ? ? ??事务A读取数据的时候允许事务B修改，但是必须等事务B提交后才能读到修改后的数据。这会存在不可重复读的问题（同一个事务范围内，两次相同的查询返回了不同的数据）。
可重复读（行锁）：
? ? ?? 事务A读取数据的时候会对那一行的数据加锁，从而不允许其他事务修改或删除这一行数据（update、delete），但是由于不是表锁所以无法阻止新数据的增加（insert）。这能够解决不可重复读的问题，但是会存在虚读/幻读的问题。
串行化（表锁）：
? ? ??不管是读还是写请求，所有的事务通过加表锁的方式保证串行化顺序执行。
多事务读写不加控制会导致数据隔离性的问题情景有：脏读、不可重复读、幻读/虚读
- 脏读：一个事务读取到了另一个事务未提交的数据。
- 不可重复读：一个事务中，同一条数据，两次读的结果不一样。
- 幻读：读到之前没有出现过的数据或者数据总量不一致(新增)。如果所有的读取都是快
? ? ? ? ?照读，那么不会有幻读问题，只有当快照读和当前读同时存在才会产生幻读问题。
两个概念：当前读VS快照读。
- 像select lock in share mode(共享锁), select for update ,update, insert ,delete(排他锁)这些操作都是一种当前读。它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。
- 像不加锁的select操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于多版本并发控制，快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。
MVCC，多版本并发控制，即一行数据可能存在多个不同的版本数据。在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突（通过不加锁的方式实现RR隔离级别），做到即使有读写冲突时，也能做到不加锁，非阻塞并发读。MVCC解决了脏读和不可重复读的问题，实现了读已提交和可重复读的事务隔离级别。
MVCC的核心原理是，依赖记录中的 3个隐式字段，undo日志 ，读视图来实现的。
【隐式字段】：每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_TRX_ID,DB_ROLL_PTR,DB_ROW_ID等字段。
- DB_ROW_ID
6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引- DB_TRX_ID
6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID（事务不需要提交），并不是当前session的事务ID- DB_ROLL_PTR
7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment里）- 实际还有一个删除flag隐藏字段, 既记录被更新或删除并不代表真的删除，而是删除flag变了
【undo 日志】：主要分insert undo log和update undo log两种。
- insert undo log
代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃。- update undo log
事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。对MVCC有帮助的实质是update undo log ，undo log实际上就是存在rollback segment中旧记录链。
【Read View】：当前事务执行快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID（即未提交的事务，且不会包括快照读的自己）。按理说，每个事务访问的每一行记录都有自己的一个读视图，用于判断其他事务对当前行的修改是否对当前事务可见。
- 三个主要的属性：
- 判断可见性的算法：
? ?总结，判断可见性的三个步骤：
? ? ?1.看当前记录对应版本的事务编号DB_TRX_ID是否在[minActiveID,maxActiveID)区间内。
? ? ?2.如果不在区间内，
? ? ? ? ? ? if DB_TRX_ID <?minActiveID，则当前事务对该版本的记录可见；
? ? ? ? ? ? if?DB_TRX_ID >=?maxActiveID，则当前事务对该版本的记录不可见。
? ? ?3.如果在区间内，判断DB_TRX_ID所属的事务是否仍在活跃列表，
? ? ? ? ? ? if contains，则当前事务对该版本的记录不可见（因为活跃代表还没commit）；
? ? ? ? ? ? if not contains，则当前事务对该版本的记录可见。
MVCC都实现了RC和RR隔离级别，那么读已提交和可重复读级别下的InnoDB快照读有什么不同？或者说MVCC具体是怎么做来区分这两种隔离级别的？
- 在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View，所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View，所以对之后的修改不可见；即RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见的。
- 而在RC级别的事务中，每次快照读都会重新生成一个快照和Read View，只要我们在新的事务修改提交后再次进行快照读，就总是可以看到别的事务提交的更新。但这会导致同一条数据，两次读取的结果不一样，即不可重复读的问题。
- 一句话讲明白，RC级别可以读到在当前事务每次快照读之前，其他已提交事务的修改操作；而RR级别只能读到当前事务第一次进行快照读之前的其他已提交事务的修改操作。RR级别其实是在RC级别的基础上解决了不可重复读的问题。
总之在RC隔离级别下，是每个快照读都会生成并获取最新的Read View；而在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。正是Read View生成时机的不同，从而造成RC,RR级别下快照读的结果的不同。
MyISAM 与 InnoDB在事务上的区别：
????????1、MyISAM是非事务安全的，而InnoDB是事务安全的
????????2、MyISAM锁的粒度是表级的，而InnoDB支持行级锁????????
? ? ? ? 3、MyISAM管理非事务表，提供高速存储和检索以及全文搜索能力，如果在应用中执行大量select操作可选择。
? ? ? ? 4、InnoDB用于事务处理，具有ACID事务支持等特性，如果在应用中执行大量insert和update操作，可选择。
? ? ? ? 5、MyISAM支持全文类型索引，而InnoDB不支持全文索引
? ? ? ? 6、MyISAM相对简单，小型应用可以考虑使用MyISAM
? ? ? ? 7、MyISAM表保存成文件形式，跨平台使用更加方便