mysql日志

保证事物原子性，通过undo log日志，我们在进行数据的新增和修改的时候，会产生undo log日志，默认为innodb存储引擎，因为这个存储引擎支持事务，

在我们对数据进行 新增 的时候，插入表之前会产生一个undo log日志，这个日志记录着我们新增的信息（id，序号等），

在回滚的时候只需要找到对应的id进行删除即可

 

在我们对数据进行 修改 的时候，插入表之前会产生一个undo log日志，这个日志记录着我们更改前的信息，对一条记录，更改每次都会产生一个新的undo log，新的undo log指向旧的undo log，通过指针进行链接

在回滚的时候，按照指针依次回滚即可

 

mysql保证持久性，通过reod log日志来保证持久性

mysql修改数据，不是直接操作磁盘，而是操作内存，

redo log又叫“重做日志”,是存储引擎层 (innoDB) 生成的日志，记录的是"物理级别"上的页修改操作，比如页号x，偏移量y写入了'z'数据（我在第几页，第几行，第几列，插入了什么数据），主要目的为了保证数据不丢失，当MySQL发生宕机的时候，可以利用redo log日志进行数据恢复，如下图所示。

 默认的redo log日志文件为ib_logfile0, ib_logfile1，如下图：

 

 

性能不够，缓存来凑。由于CPU的性能远远大于磁盘，（把数据页加载到缓冲池，然后从缓冲池里面拿数据，拿到内存）

redo log侧重于重做！redo log中记录的是物理层面的数据页、偏移量。应对的问题是：MySQL异常宕机后，如何将没来得及提交的事物数据重做出来。

1. 先将原始数据从磁盘中读入到Buffer Pool中
2. 修改Buffer Pool中的数据 ，生成一条重做日志（这个日志就是"物理级别"上的页修改操作）并写入redo log buffer，记录数据修改后的值，这张图看不明白看下一张图

3. 

    

4. 在redo log buffer，如上图，产生的redo log 先写入redo log block。然后redo log block其实就在redo log buffer 中。
5. 当事务提交时，将redo log buffer中的内容追加磁盘中的redo log文件中（先到文件再到磁盘）{到磁盘是刷盘，当redo log buffer大小超过设置大小的一半时，也会另开线程进行刷盘}
6. 将磁盘日志文件redo log file 内容刷到数据库表中

7. 那想过为什么要"多此一举"先写入到redo log磁盘文件中，然后再落到数据库表中？而不直接落到数据库表中？

   主要是因为顺序IO性能远高于随机IO。

   数据在MySQL中存储是以页为单位，事务中的数据可能遍布在不同的页中，如果直接写入到对应的页中，是随机IO写入。

   而redo log是通过顺序IO"追加"的方式写入到文件末尾，而且写入的内容也是物理日志（实打实的），比如，某个事务将系统表空间中第10号页面中偏移量为 100 处的那个字节的值 1 改成 2等信息，日志占用空间也很小。