1.MVCC（多版本并发控制）机制
MySQL 在默认的可重复读保证了事务较高的隔离性，同样的一条查询 SQL，在一个事务中，多次执行查询即使其他事务已提交的修改也不会影响当前事务SQL的查询结果。这种隔离性就是依靠 MVCC (Multi-Version Concurrency Control) 机制 来实现的（可串行化是加互斥锁）。MySQL在读已提交和可重复读隔离级别下都实现了 MVCC 机制。通过 MVCC 机制避免了频繁加锁影响性能也保证了较高的隔离性。
1.1.MVCC机制实现原理undo日志版本链与read view机制
MVCC机制实现原理： 通过 read-view 机制与 undo 版本链比对机制，使得不同的事务会根据数据版本链对比规则读取同一条数据在版本链上的不同版本数据。
undo 日志版本链： 一行数据被多个事务依次修改过后，在每个事务修改完后，MySQL 会保留修改前的数据 undo 回滚日志，并且用两个隐藏字段 trx_id 和 roll_pointer 把这些 undo 日志串联起来形成一个历史记录版本链（如下图）。
前面两行是该表中的一行记录，后面两个维护的隐藏字段
trx_id（事务ID）和 roll_pointer（指向上一次修改的记录），蓝色表示当前记录，红色表示以前的版本。组成undo日志和一条完整的undo日志版本链。
可重复读隔离级别中，当事务开启后，执行任何查询SQL（innoDB）时就会生成当前事务的一致性视图 read-view，该视图在事务结束之前都不会变化(读已提交是每次查询时都会生成新的)。
开启事务的 begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作InnoDB表的语句， 事务才真正启动，才会向 MySQL 申请事务 ID，MySQL 内部是严格按照事务的启动顺序来分配事务 ID 的。
read view的组成： 执行查询时所有未提交事务 id 数组（数组里最小的id为 min_id ）和已创建的最大事务id（max_id）组成。事务里的任何 SQL 查询结果都需要从对应版本链里的最新数据开始逐条跟 read-view 做比对从而得到最终的快照结果。
MySQL 中将事务分为三个区间，如上图，未提交事务的事务 ID 一定大于 min_id，已提交事务的事务ID不一定大于 min_id，事务ID大于 max_id 一定是未开始事务。
版本链比对规则：
- 如果 row 的 trx_id 落在绿色部分( trx_id<min_id )，表示这个版本是已提交的事务生成的，这个数据是可见的；
- 如果 row 的 trx_id 落在红色部分( trx_id>max_id )，表示这个版本是由将来启动的事务生成的，是不可见的(若 row 的 trx_id 就是当前自己的事务是可见的）；
- 如果 row 的 trx_id 落在黄色部分(min_id <=trx_id<= max_id)，那就包括两种情况
- a. 若 row 的 trx_id 在视图数组中，表示这个版本是由还没提交的事务生成的，不可见(若 row 的 trx_id 就是当前自 己的事务是可见的)；
- b. 若 row 的 trx_id 不在视图数组中，表示这个版本是已经提交了的事务生成的，可见。
对于删除的情况可以认为是 update 的特殊情况，会将版本链上最新的数据复制一份，然后将trx_id修改成删除操作的 trx_id，同时在该条记录的头信息（record header）里的（deleted_flag）标记位写上true，来表示当前记录已经被删除，在查询时按照上面的规则查到对应的记录如果delete_flag标记位为true，意味着记录已被删除，则不返回数据。
BufferPool缓存机制
磁盘随机读写的性能非常差的，直接更新磁盘文件在高并发的情况下是不可行的。所以，MySQL提供了一套 BufferPool 缓存机制。保证每个更新请求都是更新内存 BufferPool，然后顺序写日志文件，同时还能在各种异常情况下也保证数据的一致性。 更新内存性能极高，顺序写效率也远高于随机读写磁盘文件。BufferPool 机制使得 MySQL 在较高配置的机器上每秒可以并发几千的读写请求。
