读的类型

在RR级别中，通过MVCC机制，虽然让数据变得可重复读，但我们读到的数据可能是历史数据，是不及时的数据，不是数据库当前的数据！这在一些对于数据的时效特别敏感的业务中，就很可能出问题。
对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)

数据库状态的快照适用于事务中的SELECT语句, 而不一定适用于所有DML语句。 如果您插入或修改某些行, 然后提交该事务, 则从另一个并发REPEATABLE READ事务发出的DELETE或UPDATE语句就可能会影响那些刚刚提交的行, 即使该事务无法查询它们。 如果事务更新或删除由不同事务提交的行, 则这些更改对当前事务变得可见。
如：在客户端1中插入一条id为4的新数据 (直接自动提交)

mysql> insert into test_transaction (`id`,`user_name`,`age`,`gender`,`desctiption`) values (4, '死侍', 18, 0, 'A bad boy');
Query OK, 1 row affected (0.00 sec)
mysql> select * from test_transaction;
+----+-----------+-----+--------+--------------------+
| id | user_name | age | gender | desctiption        |
+----+-----------+-----+--------+--------------------+
|  1 | 金刚狼 | 127 |      1 | 我有一双铁爪 |
|  2 | 钢铁侠 | 120 |      1 | 我有一身铁甲 |
|  3 | 绿巨人 |   0 |      2 | 我有一身肉    |
|  4 | 死侍    |  18 |      0 | A bad boy          |
+----+-----------+-----+--------+--------------------+
4 rows in set (0.00 sec)
mysql> 

在客户端2事务中再次查询数据, 发现数据没有变化(表示可以重复读, 并且克服了幻读)!! 但是在客户端2事务中插入一条id为4的新数据, 发现提示数据已经存在!!!

mysql> begin;
Query OK, 0 rows affected (0.00 sec)
 
mysql> select * from test_transaction;
+----+-----------+-----+--------+--------------------+
| id | user_name | age | gender | desctiption        |
+----+-----------+-----+--------+--------------------+
|  1 | 金刚狼 | 127 |      1 | 我有一双铁爪 |
|  2 | 钢铁侠 | 120 |      1 | 我有一身铁甲 |
|  3 | 绿巨人 |   0 |      2 | 我有一身肉    |
+----+-----------+-----+--------+--------------------+
3 rows in set (0.00 sec)
 
mysql> select * from test_transaction;
+----+-----------+-----+--------+--------------------+
| id | user_name | age | gender | desctiption        |
+----+-----------+-----+--------+--------------------+
|  1 | 金刚狼 | 127 |      1 | 我有一双铁爪 |
|  2 | 钢铁侠 | 120 |      1 | 我有一身铁甲 |
|  3 | 绿巨人 |   0 |      2 | 我有一身肉    |
+----+-----------+-----+--------+--------------------+
3 rows in set (0.00 sec)
 
mysql> insert into test_transaction (`id`,`user_name`,`age`,`gender`,`desctiption`) values (4, '死侍', 18, 0, 'A bad boy');
1062 - Duplicate entry '4' for key 'PRIMARY'
mysql> 
 
//并且, 此时`update/delete`也是可以操作这条在事务中看不到的记录的!

注 如果上面的事务一直没提交而第二个事务尝试插入同一条数据的话，那么会挂起等待，这个就是第一个事务持有锁，第二个事务等待锁的体现。而如果上一个事务添加提交了，但是第二个事务还是没有提交，那么第二个事务不能查询到第一个事务插入的结果，但也不能成功的插入同一条数据。（这特么不是幻读的一种体现么？？？）也就是说在这种情况下，第一个事务已经提交了，数据库中确实有数据了，但是第二个事务就是读不到。。

继续研究下 如果我们把事务隔离级别提高到串行化呢

（事务1先添加 事务二扫描后再添加）

SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE]
//可以分别给 链接会话，全局 设置事务隔离级别  
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE
//此时只影响当前事务
select @@tx_isolation
//查看事务

实验发现：
如果事务一为串行化，事务二为rr的情况下，没有变化。
如果事务一为rr，事务二为串行化

1559897942(1).png

事务一没提交时，事务二的select操作就挂起了，串行化下select需要事务一持有的锁!
事务二先select后，事务一insert也会挂机

1559898369(1).png

可以看到等待锁的详情 事务二的普通select即持有s锁

1559898391(1).png

而97424则需要持有x锁，苦等中直到事务二commit后释放锁。

而这个也可以看出加锁不是事务一开始就加锁的而是在执行到具体语句才上锁的，毕竟人家要知道你需要加什么锁。

可见事务一二 两个持有锁不提交下冲突多

那么当事务一开启 事务二开启，事务一先添加后提交，事务二再次去查找会不会出现rr快照读下读不到数据但是也不能插入的情况呢？？
答案显然易见：
由于不是快照读，串行化的事务二是可以实时读到事务一插入的数据的。

总结

快照读下 这个事务一直读的就是最后存在的事务版本的数据，其他事务在此期间写入新数据了不会影响到这个快照读，这个快照读一直会读这个版本的数据
但是会影响update insert delete等当前读的操作，因为当前读操作的的是实时的当前数据，事务并发时 会争夺锁 ，事务一方提交了数据后数据，尽管由于当前读读历史版本读不到数据，但是他是实时存在表中的，insert,update等当前读操作都会有冲突。

再来看一下幻读的定义，到底不可重复读和幻读的区别是什么，就是不可重复读是update一条数据，而幻读是insert，后再次select的幻影么，是一个单挑数据一个范围么？

[幻读]

幻读定义

不可重复读

快照读(snapshot read)

读取历史数据，不是最新数据
简单select操作，select **

快照读的意义

MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。

当前读(current read)

读最新数据
select ** lock in share mode
select ** for update
insert
update
delete
所有以上的语句，都属于当前读，读取记录的最新版本。并且，读取之后，还需要保证其他并发事务不能修改当前记录，对读取记录加锁。其中，除了第一条语句，对读取记录加S锁 (共享锁)外，其他的操作，都加的是X锁 (排它锁)。
（为什么 insert update delete 也属于当前读）

一个Update操作的具体流程。当Update SQL被发给MySQL后，MySQL Server会根据where条件，读取第一条满足条件的记录，然后InnoDB引擎会将第一条记录返回，并加锁 (current read)。待MySQL Server收到这条加锁的记录之后，会再发起一个Update请求，更新这条记录。一条记录操作完成，再读取下一条记录，直至没有满足条件的记录为止。因此，Update操作内部，就包含了一个当前读。同理，Delete操作也一样。Insert操作会稍微有些不同，简单来说，就是Insert操作可能会触发Unique Key的冲突检查，也会进行一个当前读。

一致性非锁定读

指的是如果一条记录被加了X锁，其他事务还能读取这条记录。

一致性锁定读

指的是一个事务可以通过SELECT语句给某条记录加X锁或者X锁。

锁

s锁与X锁

共享锁【S锁】
又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

排他锁【X锁】
又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。

IS锁和IX锁

兼容矩阵

事务隔离级别与锁

MVVC 与 redo Log undo Log

行多版本将的是innodb为每个行记录存储了多个版本，记住，这里是多个版本不是两个版本，在刚开始接触多版本的时候，我的疑问是innodb对每个行要存储多个版本是多么浪费存储空间呀？然而进一步了解，原来所谓的多版本只是innodb聪明地撒了个谎，多个版本是通过undo日志实现的，这里可以理解为既然undo日志包括了所有用来恢复历史版本数据的信息，那么我们只要将“不同版本”指针指向不同时间节点的undo日志即可，这样读取的时候通过对不同时间节点的undo日志进行恢复从而得到不同的版本数据。同时对于undo日志的读取是不需要加锁的，因此这极大地提高了数据库的并发性。

聚集索引 非聚集索引

数据库死锁

数据库所记录 事务记录

首先说结论，在RR的隔离级别下，Innodb使用MVVC和next-key locks解决幻读，MVVC解决的是普通读（快照读）的幻读，next-key locks解决的是当前读情况下的幻读。

MVCC：多版本并发控制（MVCC,Multiversion Currency Control）。一般情况下，事务性储存引擎不是只使用表锁，行加锁的处理数据，而是结合了MVCC机制，以处理更多的并发问题。Mvcc处理高并发能力最强，

但系统开销 比最大（较表锁、行级锁），这是最求高并发付出的代价。

** InnoDB实现MVCC的方法是，它存储了每一行的三个额外的隐藏字段:**

1.DB_TRX_ID：一个6byte的标识，每处理一个事务，其值自动+1 #下面提到的“创建时间”和“删除时间”记录的就是这个DB_TRX_ID的值 #如insert、update、delete操作时，删除操作用1个bit表示。 #DB_TRX_ID是最重要的一个，可以通过语句“show engine innodb status”来查找 2.DB_ROLL_PTR: 大小是7byte,指向写到rollback segment（回滚段）的一条undo log记录 （update操作的话，记录update前的ROW值） 3.DB_ROW_ID: 大小是6byte,该值随新行插入单调增加。 #当由innodb自动产生聚集索引时聚集索引(即没有主键时,因为MYSQL默认聚簇表,会自动生成一个ROWID) #包括这个DB_ROW_ID的值， #不然的话聚集索引中不包括这个值,这个用于索引当中。

DB_TRX_ID记录了行的创建的时间删除的时间在每个事件发生的时候，每行存储版本号，而不是存储事件实际发生的时间。每次事物的开始这个版本号都会增加。自记录时间开始，每个事物都会保存记录的系统版本号

依照事物的版本来检查每行的版本号。在insert操作时 “创建时间”=DB_TRX_ID，这时，“删除时间”是未定义的；在update时，复制新增行的“创建时间”=DB_TRX_ID，删除时间未定义，旧数据行“创建时间”不变，

删除时间=该事务DB_TRX_ID；delete操作，相应数据行的“创建时间”不变，删除时间=该事务的DB_ROW_ID；select操作对两者都不修改，只读相应的数据

MVCC结合隔离级别:
1.READ UNCOMMITTED ，不适用MVCC读，可以读到其他事务修改甚至未提交的 2.READ COMMITTED ，其他事务对数据库的修改,只要已经提交,其修改的结果就是可见的, 与这两个事务开始的先后顺序无关，不完全适用于MVCC读， 3.REPEATABLE READ，可重复读，完全适用MVCC，只能读取在它开始之前已经提交的事务对数据库的修改, 在它开始以后,所有其他事务对数据库的修改对它来说均不可见 4.SERIALIZABLE ，完全不适合适用MVCC，这样所有的query都会加锁，再它之后的事务都要等待

MVCC只工作在REPEATABLE READ和READ COMMITED隔离级别下

2 REPEATABLE READ 可重复读下的MVCC

SELECT

Innodb检查每行数据，确保他们符合两个标准： 1.InnoDB只查找版本早于当前事务版本的数据行（也就是数据行的版本必须小于等于事务的版本），这确保当前事务 读取的行都是事务之前已经存在的，或者是由当前事务创建或修改的行 2.行的删除操作的版本一定是未定义的或者大于当前事务的版本号。确定了当前事务开始之前，行没有被删除 　 符合了以上两点则返回查询结果。

INSERT

InnoDB为每个新增行记录当前系统版本号作为创建ID。

DELETE

InnoDB为每个删除行的记录当前系统版本号作为行的删除ID。

UPDATE

InnoDB复制了一行。这个新行的版本号使用了系统版本号。它也把系统版本号作为了删除行的版本。

3 MVCC深入

如果根据事务DB_TRX_ID去比较获取事务的话，按道理在一个事务B（在事务A后，但A还没commit）select的话 B.DB_TRX_ID>A.DB_TRX_ID则应该能返回A事务对数据的操作以及修改。那不是和前面矛盾？其实不然。

InnoDB每个事务在开始的时候，会将当前系统中的活跃事务列表（trx_sys->trx_list）创建一个副本（read view），然后一致性读去比较记录的tx id的时候，并不是根据当前事务的tx id，而是根据read view最早一个事务的tx id（read view->up_limit_id）来做比较的，这样就能确保在事务B之前没有提交的所有事务的变更，B事务都是看不到的。当然，这里还有个小问题要处理一下，就是当前事务自身的变更还是需要看到的。

READ-COMMITTED 与 REPEATABLE-READ区别
都依赖于read view、 undo log

read view: 主要用来判断当前版本数据的可见性。 通过数据表版本号实现，见已整理乐观锁的过程

在innodb中，创建一个新事务的时候，innodb会将当前系统中的活跃事务列表（trx_sys->trx_list）创建一个副本（read view），副本中保存的是系统当前不应该被本事务看到的其他事务id列表。当用户在这个事务中要读取该行记录的时候，innodb会将该行当前的版本号与该read view进行比较。

undo log
undo log是为回滚而用，把所有没有COMMIT的事务回滚到事务开始前的状态

具体内容就是copy事务前的数据库内容（行）到undo buffer，在适合的时间把undo buffer中的内容刷新到磁盘

undo buffer与redo buffer一样，也是环形缓冲，但当缓冲满的时候，undo buffer中的内容会也会被刷新到磁盘；与redo log不同的是，磁盘上不存在单独的undo log文件，所有的undo log均存放在主ibd数据文件中（表空间），即使客户端设置了每表一个数据文件也是如此。

redo log 重做日志信息 先写入 重做日志缓冲 再按一定条件顺序写入重做日志文件！
所有对页面的修改操作写入一个专门的文件，在回放日志的时候把已经COMMIT的事务重做一遍

事务隔离级别的影响
　tx_isolation='READ-COMMITTED': 语句级别的一致性：只要当前语句执行前已经提交的数据都是可见的。

tx_isolation='REPEATABLE-READ'; 语句级别的一致性：只要是当前事务执行前已经提交的数据都是可见的。

针对这两张事务的隔离级别，使用相同的可见性判断逻辑是如何做到不同的可见性的呢

不同隔离级别下read view的生成原则

1. read-commited: 每次执行重新创建read_view

在每次语句执行的过程中，都关闭read_view, 重新在row_search_for_mysql函数中创建当前的一份read_view

这样就可以根据当前的全局事务链表创建read_view的事务区间，实现read committed隔离级别

2. repeatable read：执行之前创建read_view

在repeatable read的隔离级别下，创建事务trx结构的时候，就生成了当前的global read view

使用trx_assign_read_view函数创建，一直维持到事务结束，这样就实现了repeatable read隔离级别

正是因为read view 生成原则不同，导致在不同隔离级别()下,read committed 总是读最新一份快照数据

而repeatable read 读事务开始时的行数据版本

当前读

而每一个事务在启动的时候，都有一个唯一的递增的版本号。每开启一个新事务，事务的版本号就会递增。
所谓当前读，指的是加锁的select(S或者X), update, delete等语句。在RR的事务隔离级别下，数据库会使用next-key locks来锁住本条记录以及索引区间。

拿上面那个例子来说，在RR的情况下，假设使用的是当前读，加锁了的读

select * from table where id>3 锁住的就是id=3这条记录以及id>3这个区间范围，锁住索引记录之间的范围，避免范围间插入记录，以避免产生幻影行记录。
在InnoDB中，每一行都有2个隐藏列DATA_TRX_ID和DATA_ROLL_PTR（如果没有定义主键，则还有个隐藏主键列ROWID）：
DATA_TRX_ID: 表示最近修改的事务的id
DATA_ ROLL_PTR: 表示指向该行回滚段(undo segment 中的 undo log)的指针，该行上所有旧的版本，在undo中都通过链表的形式组织，而该值，正式指向undo中该行的历史记录链表

#######普通读

官方文档上说mysql是支持非锁定读的；这个功能是这样实现的，如果事务a 要对行的数据进行更新的话，那么事务a要得到行的x锁，并把这一行

之前的样子记录在undo log里面，这样一来如果a 事务rollback 了就可以通过undo log 来恢复到之前的样子；说白了非锁定的一致性读就是读的

行的undo log 中的内容，所以这货根本就不用上锁。

2、在mysql中事务与锁的关系：

1、事务开始之后申请锁。

2、得到锁之后才进行相关的操作，事务提交或回滚之后才会去释放申请到的锁。

3、如果想要select 语句也加上s锁可以在select 后面加上lock in share mode 子句。

4、mysql支持意向锁、意向锁是在表级别上的；

image

5、innodb 对锁的分配方式：

1、innodb 的锁是需要用到的时候才会去分配，并是一次性要把事务要用到的锁分配完成后才去执行事务。

2、对锁的申请请求是放在一个队列当中的，请申请的先得到。

mvvc 与幻读

3.1. 当前读
所谓当前读，指的是加锁的select(S或者X), update, delete等语句。在RR的事务隔离级别下，数据库会使用next-key locks来锁住本条记录以及索引区间。

拿上面那个例子来说，在RR的情况下，假设使用的是当前读，加锁了的读

select * from table where id>3 锁住的就是id=3这条记录以及id>3这个区间范围，锁住索引记录之间的范围，避免范围间插入记录，以避免产生幻影行记录。

3.2. 普通读
因为普通读是不会加锁的读，故不会有next-key locks的使用，解决幻读的手段是MVVC

mvvc会给每行元组加一些辅助字段，记录创建版本号和删除版本号。

而每一个事务在启动的时候，都有一个唯一的递增的版本号。每开启一个新事务，事务的版本号就会递增。

默认的隔离级别（REPEATABLE READ）下，增删查改变成了这样：

SELECT
读取创建版本小于或等于当前事务版本号，并且删除版本为空或大于当前事务版本号的记录。这样可以保证在读取之前记录是存在的
INSERT
将当前事务的版本号保存至行的创建版本号
UPDATE
新插入一行，并以当前事务的版本号作为新行的创建版本号，同时将原记录行的删除版本号设置为当前事务版本号
DELETE
将当前事务的版本号保存至行的删除版本号

比如我插入一条记录, 事务id 假设是1 ，那么记录如下：也就是说，创建版本号就是事务版本号。

1559894784(1).png

如果我更新的话，事务id假设是2

1559894835(1).png

这里是把name更新为taotao，原来的元组deleteversion版本号为这个事务的id，并且新增一条

如果我删除的话，假设事务是id=3

1559894862(1).png

就变成现在这个样子

关键点来了

现在我读取的话，必须同时满足两个条件的

读取创建版本小于或等于当前事务版本号 这意味着数据在这个事务之前被创建
删除版本为空或大于当前事务版本号的记录。 这意味着删除操作在这个事务之后发生

就拿上面那个例子说明

当前数据库的状态

image.png

假设事务A的id=10

现在update table set name=“hh” where id>3;执行这条语句

image.png

事务B的id=11

insert into table values(11, uu);

1559894954(1).png

最后事务A（id=10）在此读取

select * from table where id>3

根据上述的规则，

读取创建版本好小于等于当前事务的→那么（4，a）（5，b）（4，hh）（5，hh）

上面规则的输出作为下面规则的输入的话

删除版本为空或大于当前事务版本号的记录→（4，hh）（5，hh）

如此读取就没有读取到事务B新插入的那行，解决幻读

如果事务B是更新id=4 的元组name=cc呢

同理，根据update的规则

image.png

然后根据select的规则去读取的话，得到的还是（4，hh）（5，hh）

4. 多说一句
   在RC的模式下，MVVC解决不了幻读和不可重复读，因为每次读都会读它自己刷新的快照版本，简单来说就是另一个事务提交，他就刷新一次，去读最新的

redo log日志模块

redo log是InnoDB存储引擎层的日志，又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。

在一条更新语句进行执行的时候，InnoDB引擎会把更新记录写到redo log日志中，然后更新内存，此时算是语句执行完了，然后在空闲的时候或者是按照设定的更新策略将redo log中的内容更新到磁盘中，这里涉及到WAL即Write Ahead logging技术，他的关键点是先写日志，再写磁盘。

有了redo log日志，那么在数据库进行异常重启的时候，可以根据redo log日志进行恢复，也就达到了crash-safe。

redo log日志的大小是固定的，即记录满了以后就从头循环写。

binlog日志模块

binlog是属于MySQL Server层面的，又称为归档日志，属于逻辑日志，是以二进制的形式记录的是这个语句的原始逻辑，依靠binlog是没有crash-safe能力的

redo log和binlog区别

• redo log是属于innoDB层面，binlog属于MySQL Server层面的，这样在数据库用别的存储引擎时可以达到一致性的要求。
• redo log是物理日志，记录该数据页更新的内容；binlog是逻辑日志，记录的是这个更新语句的原始逻辑
• redo log是循环写，日志空间大小固定；binlog是追加写，是指一份写到一定大小的时候会更换下一个文件，不会覆盖。
• binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。

一条更新语句执行的顺序
update T set c=c+1 where ID=2;

执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

数据库数据存放的文件称为data file；日志文件称为log file；数据库数据是有缓存的，如果没有缓存，每次都写或者读物理disk，那性能就太低下了。数据库数据的缓存称为data buffer，日志（redo）缓存称为log buffer；既然数据库数据有缓存，就很难保证缓存数据（脏数据）与磁盘数据的一致性。比如某次数据库操作：

update driver_info set driver_status = 2 where driver_id = 10001;

更新driver_status字段的数据会存放在缓存中，等待存储引擎将driver_status刷新data_file，并返回给业务方更新成功。如果此时数据库宕机，缓存中的数据就丢失了，业务方却以为更新成功了，数据不一致，也没有持久化存储。

上面的问题就可以通过事务的ACID特性来保证。

BEGIN trans；

update driver_info set driver_status = 2 where driver_id = 10001;

COMMIT;

这样执行后，更新要么成功，要么失败。业务方的返回和数据库data file中的数据保持一致。要保证这样的特性这就不得不说存储引擎innodb的redo和undo日志。

redo日志、undo日志：

存储引擎也会为redo undo日志开辟内存缓存空间，log buffer。磁盘上的日志文件称为log file，是顺序追加的，性能非常高，注：磁盘的顺序写性能比内存的写性能差不了多少。

undo日志用于记录事务开始前的状态，用于事务失败时的回滚操作；redo日志记录事务执行后的状态，用来恢复未写入data file的已成功事务更新的数据。例如某一事务的事务序号为T1，其对数据X进行修改，设X的原值是5，修改后的值为15，那么Undo日志为<T1, X, 5>，Redo日志为<T1, X, 15>。

梳理下事务执行的各个阶段：

（1）写undo日志到log buffer；

（2）执行事务，并写redo日志到log buffer；

（3）如果innodb_flush_log_at_trx_commit=1，则将redo日志写到log file，并刷新落盘。

（4）提交事务。

可能有同学会问，为什么没有写data file，事务就提交了？

在数据库的世界里，数据从来都不重要，日志才是最重要的，有了日志就有了一切。

因为data buffer中的数据会在合适的时间 由存储引擎写入到data file，如果在写入之前，数据库宕机了，根据落盘的redo日志，完全可以将事务更改的数据恢复。好了，看出日志的重要性了吧。先持久化日志的策略叫做Write Ahead Log，即预写日志。

分析几种异常情况：

• innodb_flush_log_at_trx_commit=2（innodb_flush_log_at_trx_commit和sync_binlog参数详解）时，将redo日志写入logfile后，为提升事务执行的性能，存储引擎并没有调用文件系统的sync操作，将日志落盘。如果此时宕机了，那么未落盘redo日志事务的数据是无法保证一致性的。
• undo日志同样存在未落盘的情况，可能出现无法回滚的情况。

checkpoint：

checkpoint是为了定期将db buffer的内容刷新到data file。当遇到内存不足、db buffer已满等情况时，需要将db buffer中的内容/部分内容（特别是脏数据）转储到data file中。在转储时，会记录checkpoint发生的”时刻“。在故障回复时候，只需要redo/undo最近的一次checkpoint之后的操作。

重做日志（redo log）

作用：
确保事务的持久性。
防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。
内容：
物理格式的日志，记录的是物理数据页面的修改的信息，其redo log是顺序写入redo log file的物理文件中去的。
什么时候产生：
事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。
什么时候释放：
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。
对应的物理文件：
默认情况下，对应的物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2
innodb_log_group_home_dir 指定日志文件组所在的路径，默认./ ，表示在数据库的数据目录下。
innodb_log_files_in_group 指定重做日志文件组中文件的数量，默认2
关于文件的大小和数量，由一下两个参数配置
innodb_log_file_size 重做日志文件的大小。
innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认1
其他：
很重要一点，redo log是什么时候写盘的？前面说了是在事物开始之后逐步写盘的。
之所以说重做日志是在事务开始之后逐步写入重做日志文件，而不一定是事务提交才写入重做日志缓存，
原因就是，重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为8M(这里设置的16M),Innodb存储引擎先将重做日志写入innodb_log_buffer中。

image

然后会通过以下三种方式将innodb日志缓冲区的日志刷新到磁盘
1，Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件。
2，每个事务提交时会将重做日志刷新到重做日志文件。
3，当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件
由此可以看出，重做日志通过不止一种方式写入到磁盘，尤其是对于第一种方式，Innodb_log_buffer到重做日志文件是Master Thread线程的定时任务。
因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。
另外引用《MySQL技术内幕 Innodb 存储引擎》（page37）上的原话：
即使某个事务还没有提交，Innodb存储引擎仍然每秒会将重做日志缓存刷新到重做日志文件。
这一点是必须要知道的，因为这可以很好地解释再大的事务的提交（commit）的时间也是很短暂的。

回滚日志（undo log）

作用：
保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读

内容：
逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。

什么时候产生：
事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性

什么时候释放：
当事务提交之后，undo log并不能立马被删除，
而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。

对应的物理文件：
MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中。
MySQL5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数
如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。
关于MySQL5.7之后的独立undo 表空间配置参数如下
innodb_undo_directory = /data/undospace/ –undo独立表空间的存放目录
innodb_undo_logs = 128 –回滚段为128KB
innodb_undo_tablespaces = 4 –指定有4个undo log文件

如果undo使用的共享表空间，这个共享表空间中又不仅仅是存储了undo的信息，共享表空间的默认为与MySQL的数据目录下面，其属性由参数innodb_data_file_path配置。

image

其他：
undo是在事务开始之前保存的被修改数据的一个版本，产生undo日志的时候，同样会伴随类似于保护事务持久化机制的redolog的产生。
默认情况下undo文件是保持在共享表空间的，也即ibdatafile文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的undo信息，全部保存在共享表空间中的。
因此共享表空间可能会变的很大，默认情况下，也就是undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。
因此，mysql5.7之后的“独立undo 表空间”的配置就显得很有必要了。

二进制日志（binlog）：

作用：
1，用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。
2，用于数据库的基于时间点的还原。
内容：
逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。
但又不完全是sql语句这么简单，而是包括了执行的sql语句（增删改）反向的信息，
也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后的版本的信息；insert对应着delete和insert本身的信息。
在使用mysqlbinlog解析binlog之后一些都会真相大白。
因此可以基于binlog做到类似于oracle的闪回功能，其实都是依赖于binlog中的日志记录。

什么时候产生：
事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。
这里与redo log很明显的差异就是redo log并不一定是在事务提交的时候刷新到磁盘，redo log是在事务开始之后就开始逐步写入磁盘。
因此对于事务的提交，即便是较大的事务，提交（commit）都是很快的，但是在开启了bin_log的情况下，对于较大事务的提交，可能会变得比较慢一些。
这是因为binlog是在事务提交的时候一次性写入的造成的，这些可以通过测试验证。

什么时候释放：
binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。

image

对应的物理文件：
配置文件的路径为log_bin_basename，binlog日志文件按照指定大小，当日志文件达到指定的最大的大小之后，进行滚动更新，生成新的日志文件。
对于每个binlog日志文件，通过一个统一的index文件来组织。

image

其他：
二进制日志的作用之一是还原数据库的，这与redo log很类似，很多人混淆过，但是两者有本质的不同
1，作用不同：redo log是保证事务的持久性的，是事务层面的，binlog作为还原的功能，是数据库层面的（当然也可以精确到事务层面的），虽然都有还原的意思，但是其保护数据的层次是不一样的。
2，内容不同：redo log是物理日志，是数据页面的修改之后的物理记录，binlog是逻辑日志，可以简单认为记录的就是sql语句
3，另外，两者日志产生的时间，可以释放的时间，在可释放的情况下清理机制，都是完全不同的。
4，恢复数据时候的效率，基于物理日志的redo log恢复数据的效率要高于语句逻辑日志的binlog

关于事务提交时，redo log和binlog的写入顺序，为了保证主从复制时候的主从一致（当然也包括使用binlog进行基于时间点还原的情况），是要严格一致的，
MySQL通过两阶段提交过程来完成事务的一致性的，也即redo log和binlog的一致性的，理论上是先写redo log，再写binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成。