文章目录
原子性底层实现原理
A(原子性)，要么全部完成，要么完全不起作用。底层实现是通过undo log日志去实现的，当这个事务对数据库进行修改的时候，innodb 生成对应undo log，undolog有多个版本，并且存放的是与上一个版本相反的操作，他会记录这个SQL执行的相关信息，如果SQL执行失败发生回滚，innodb 根据这个undo log内容去做相反的工作，比如说我执行了一个insert 操作，那么回滚的时候，就会执行一个相反的操作，就是delete,对应update，回滚的时候也是执行相反的update。这就是原子性的底层实现。
一致性实现原理
一旦事务完成，不管成功还是失败，数据处于一致的状态，而不会是部分完成，部分失败。事务执行前后，数据库的完整约束没有遭受破坏，事务执行前后都是合法的一个数据状态。事务的AID是数据库的特征，也就是依赖数据库的具体实现。而唯独这个C，实际上它依赖于应用层，也就是依赖于开发者。这里的一致性，是指数据从一种正确的状态，跳转到另一种正确的状态。
举例：账户A转1000到账户B，A转账的金额，必须小于等于自己的账户余额，即事务提交时，A的账户余额不能为负数，可以通过数据库约束，保证账户金额的字段值大于等于0。
InnoDB是如何进行一致性非锁定读的（MVCC的原理）
一致性的非锁定读（consistent nonlocking read）是指InnoDB存储引擎通过行多版本控制（multi versioning）的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行DELETE或UPDATE操作，这时读取操作不会因此去等待行上锁的释放。相反地，InnoDB存储引擎会去读取行的一个快照数据。之所以称其为非锁定读，因为不需要等待访问的行上X锁的释放。快照数据是指该行的之前版本的数据，该实现是通过undo段来完成。而undo用来在事务中回滚数据，因此快照数据本身是没有额外的开销。此外，读取快照数据是不需要上锁的，因为没有事务需要对历史的数据进行修改操作。快照数据其实就是当前行数据之前的历史版本，每行记录可能有多个版本。如右图显示的，个行记录可能有不止一个快照数据，一般称种技术为行多版本技术。由此带来的并发控制，称之为多版本并发控制。
对于READ COMMITTED的事务隔离级别，它总 是读取行的最新版本，如果行被锁定了，则读取 该行版本的最新一个快照（freshsnapshot）。而对于REPEATABLE READ的事务隔离级别，总是读取事务开始时的行数据。
对于READ COMMITTED的事务隔离级别而言，从数据库理论的角度来看，其违反了事务ACID中的I的特性，即隔离性。
undo日志版本链是指一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚 日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链。
在可重复读隔离级别，当事务开启，执行任何查询sql时会生成当前事务的一致性视图read-view，该视图在事务结束 之前都不会变化(如果是读已提交隔离级别在每次执行查询sql时都会重新生成)，这个视图由执行查询时所有未提交事 务id数组（数组里最小的id为min_id）和已创建的最大事务id（max_id）组成，事务里的任何sql查询结果需要从对应 版本链里的最新数据开始逐条跟read-view做比对从而得到最终的快照结果。 版本链比对规则：
如果 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，意味着记录已被删除，则不返回数 据。
注意：begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个修改操作InnoDB表的语句， 事务才真正启动，才会向mysql申请事务id，mysql内部是严格按照事务的启动顺序来分配事务id的。
总结： MVCC机制的实现就是通过read-view机制与undo版本链比对机制，使得不同的事务会根据数据版本链对比规则读取 同一条数据在版本链上的不同版本数据。
BufferPool缓存机制
为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？
因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能可能相当差。
因为磁盘随机读写的性能是非常差的，所以直接更新磁盘文件是不能让数据库抗住很高并发的。 Mysql这套机制看起来复杂，但它可以保证每个更新请求都是更新内存BufferPool，然后顺序写日志文件，同时还能 保证各种异常情况下的数据一致性。 更新内存的性能是极高的，然后顺序写磁盘上的日志文件的性能也是非常高的，要远高于随机读写磁盘文件。 正是通过这套机制，才能让我们的MySQL数据库在较高配置的机器上每秒可以抗下几干的读写请求。
持久性底层实现原理
一旦事务完成，无论发生什么系统错误，它的结果都不会受到影响，事务的结果被写到持久化存储器中。底层实现原理是：redo log机制去实现的，mysql 的数据是存放在这个磁盘上的，但是每次去读数据都需要通过这个磁盘io，效率就很低，使用 innodb 提供了一个缓存 buffer，这个 buffer 中包含了磁盘部分数据页的一个映射，作为访问数据库的一个缓冲，从数据库读取一个数据，就会先从这个 buffer 中获取，如果 buffer 中没有，就从这个磁盘中获取，读取完再放到这个 buffer 缓冲中，当数据库写入数据的时候，也会首先向这个 buffer 中写入数据，定期将 buffer 中的数据刷新到磁盘中，进行持久化的一个操作。如果 buffer 中的数据还没来得及同步到这个磁盘上，这个时候 MySQL 宕机了，buffer 里面的数据就会丢失，造成数据丢失的情况，持久性就无法保证了。使用 redolog 解决这个问题，当数据库的数据要进行新增或者是修改的时候，除了修改这个 buffer 中的数据，还会把这次的操作写入到这个 redolog 中，如果 msyql 宕机了，就可以通过 redolog 去恢复数据，redolog 是预写式日志，会先将所有的修改写入到日志里面，然后再更新到 buffer 里面，保证了这个数据不会丢失，保证了数据的持久性，redolog 属于记录修改的操作，主要为了提交或者恢复数据使用！
事务隔离性由之前讲述的锁来实现。redo log称为重做日志，用来保证事务的持久性。redo通常是物理日志，记录的是页的物理修改操作。重做日志用来实现事务的持久性，即事务ACID中的D。其由两部分组成：n 一是内存中的重做日志缓冲（redo logbuffer），其是易失的；n 二是重做日志文件（redologfile），其是持久的。InnoDB是事务的存储引擎，其通过Force Log at Commit机制实现事务的持久性，即当事务提交（COMMIT）时，必须先将该事务的所有日志写入到重做日志文件进行持久化，待事务的COMMIT操作完成才算完成。为了确保每次日志都写入重做日志文件，在每次将重做日志缓冲写入重做日志文件后，InnoDB存储引擎都需要调用一次fsync操作。由于重做日志文件打开并没有使用O_DIRECT选项，因此重做日志缓冲先写入文件系统缓存。为了确保重做日志写入磁盘，必须进行一次fsync操作。由于fsync的效率取决于磁盘的性能，因此磁盘的性能决定了事务提交的性能，也就是数据库的性能。
重做日志刷新到磁盘的策略
通过参数innodb_flush_log_at_trx_commit用来控制重做日志刷新到磁盘的策略。n 该参数的默认值为1，表示事务提交时必须调用一次fsync操作。还可以设置该参数的值为0和2。
n 0表示事务提交时不进行写入重做日志操作，这个操作仅在master thread中完成，而在master thread中每1秒会进行一次重做日志文件的fsync操作。n 2表示事务提交时将重做日志写入重做日志文件，但仅写入文件系统的缓存中，不进行fsync操作。在这个设置下，当MySQL数据库发生宕机而操作系统不发生宕机时，并不会导致事务的丢失。而当操作系统宕机时，重启数据库后会丢失未从文件系统缓存刷新到重做日志文件那部分事务。举例：逐条插入50万条数据。innodb_flush_log_at_trx_commit = 1时： 用时 2 分 13 秒。50 万次写入重做日志；fsync操作50万次。innodb_flush_log_at_trx_commit = 0时： 用时 23 秒。约23次写如重做日志；fsync操作约23次。innodb_flush_log_at_trx_commit = 2时： 用时 35 秒。50万次写入重做日志（仅缓存）；fsync操作0次。虽然用户可以通过设置参数innodb_flush_log_at_trx_commit为0或2来提高事务提交的性能，但是需要牢记的是，这种设置方法丧失了事务的ACID特性。而针对上述存储过程，为了提高事务的提交性能，应该在将50万行记录插入表后进行一次的COMMIT操作，而不是在每插入一条记录后进行一次COMMIT操作。这样做的好处是还可以使事务方法在回滚时回滚到事务最开始的确定状态。正确方法：innodb_flush_log_at_trx_commit = 1，将50万条数据在一个事务或者多个事务中分派提交，减少fsync次数。
隔离性实现原理
多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。底层实现原理：写-写操作：通过加锁，原理和 java 里面的锁机制是一样的。写-读操作：MVCC多版本并发控制，对一行数据的读和写两个操作默认是不会通过加锁互斥来保证隔离性，避免了频繁加锁互斥。一行数据被多个事务依次修改过后，在每个事务修改完后，Mysql会保留修改前的数据undo回滚日志，并且用两个隐藏字段trx_id和roll_pointer把这些undo日志串联起来形成一个历史记录版本链。在可重复读隔离级别，事务开启的时候，执行任何查询sql会生成当前事务的一致性视图read-view，也就是第一次select生成一个版本，read-view视图在事务结束之前都不会变化。如果是读已提交隔离级别，在每次执行查询sql时都会重新生成视图read-view，也就是每次select生成一个版本。执行查询时，从对应版本链里的最新数据开始逐条跟read-view做比，会拿着当前事务的id和readview视图数组里面的已创建的最小事务id和已创建的最大事务id进行比较，这里面分为三种情况，第一种，当前事务的id小于数组里面最小的id，说明这个版本是已提交的事务生成的，表示这个数据可见。第二种，当前事务比已创建的最大事务id还要大，说明这个版本还没开启事务，表示不可见。第三种，如果刚好在这个区间，被访问的事务id在最小事务id与最大事务id之间，又有二种情况，第一种，这个版本是由还没提交的事务生成的，不可见，第二种，表示这个版本是已经提交了的事务生成的，可见。做比对，得到最终的快照结果，通过这种机制保证了隔离性。
隔离级别
SQL标准定义的四个隔离级别为：
❑READUNCOMMITTED（导致脏读）
❑READCOMMITTED（导致幻读）
❑REPEATABLE READ （默认使用，避免幻读，也能避免脏读）
❑SERIALIZABLE（更高级别隔离，避免幻读，避免脏读）
InnoDB存储引擎默认支持的隔离级别是REPEATABLE READ，但是与标准SQL不同的是，InnoDB存储引擎在REPEATABLEREAD事务隔离级别下，使用Next-Key Lock锁的算法，因此避免幻读的产生。这与其他数据库系统（如Microsoft SQLServer数据库）是不同的。所以说，InnoDB存储引擎在默认的REPEATABLE READ的事务隔离级别下已经能完全保证事务的隔离性要求，即达到SQL标准的SERIALIZABLE隔离级别。隔离级别越低，事务请求的锁越少或保持锁的时间就越短。这也是为什么大多数数据库系统默认的事务隔离级别是READCOMMITTED。
在SERIALIABLE的事务隔离级别，InnoDB存储引擎会对每个SELECT语句后自动加上LOCK IN SHARE MODE，即为每个读取操作加一个共享锁。因此在这个事务隔离级别下，读占用了锁，对一致性的非锁定读不再予以支持。
脏读/不可重复读/幻读
如果不考虑事务的隔离性，会发生的几种问题：
第一个问题是脏读，在一个事务处理过程里读取了另一个未提交的事务中的数据。举个例子，公司发工资了，领导把四万块钱打到我的账号上，但是该事务并未提交，而我正好去查看账户，发现工资已经到账，是四万，非常高兴。可是不幸的是，领导发现发给我的工资金额不对，是三万五元，于是迅速修改金额，将事务提交，最后我实际的工资只有三万五元，我就白高兴一场。
第二个问题是不可重复读，某个数据在一个事务范围内多次查询却返回了不同的结果，用大白话讲就是事务T1读取数据，事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取这个数据就得到了不同的结果，发生了不可重复读。举个例子，我拿着工资卡去消费，系统读取到卡里确实有一百块钱，这个时候我的女朋友刚好用我的工资卡在网上转账，把我工资卡的一百块钱转到另一账户，并在我之前提交了事务，当我扣款时，系统检查到我的工资卡已经没有钱，扣款失败，廖志伟十分纳闷，明明卡里有钱的。
第三个问题是幻读，事务T1对一个表的数据做了从“1”修改成“2”的操作，这时事务T2又对这个表插入了一条数据，而这个数据的值还是为“1”并且提交给数据库，操作事务T1的用户再查看刚刚修改的数据，会发现还有一行没有修改。举个例子，当我拿着工资卡去消费时，一旦系统开始读取工资卡信息，这个时候事务开始，我的女朋友就不可能对该记录进行修改，也就是我的女朋友不能在这个时候转账。这就避免了不可重复读。假设我的女朋友在银行部门工作，她时常通过银行内部系统查看我的工资卡消费记录。有一天，她正在查询到我当月信用卡的总消费金额（select sum(amount) from transaction where month = 本月）为80元，而我此时正好在外面胡吃海喝后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction … ），并提交了事务，随后我的女朋友把我当月工资卡消费的明细打印到A4纸上，却发现消费总额为1080元，我女朋友很诧异，以为出现了幻觉，幻读就这样产生了。
