对于mysql数据库日志文件的总结

一：mysql数据库中有三大日志文件，分别是redo log，undo log，以及binlog。那么这三大日志文件的作用是什么呢？

二：三大日志文件的作用

1.redo log

（1）众所周知，数据库的数据一经改变，就不可逆转。也就是常说数据的持久性。但是了解数据库的都知道，每一次数据的修改，都不是直接修改到磁盘上的，而mysql会利用自己的缓存池buffer_pool，要需要修改时，先把硬盘上的数据页加载到内存的buffer_pool中（一个数据页默认是16kb），然后在buffer_pool中修改数据，修改后，是不会立即刷到磁盘中的。但是，数据在内存中，数据库一旦重启，那又如何保证数据库的持久性呢？redo log日志正是解决这个问题的。redo日志记录的是数据的修改情况，如哪一行修改了什么值，旧值是什么，新值是什么。虽然mysql不会立即把修改后的数据刷新到磁盘，但是会把修改情况记录在redo日志中、一段时间后，mysql读取日志就苦役把最新情况更新到数据库中。这样既节省了IO次数，又可以保证事务的持久性

因此，redo文件就是用来保证事务的持久性，用来恢复未写入磁盘文件的已成功事务更新的数据的。

（2）redo文件在哪里？

通过show variables like "datadir"就可以找到data数据的路径，然后就可以看到ib_logfile0和ib_logfile1,这两个就是redo文件。mysql默认是两个。

（3）那么redo文件是什么时候产生的呢?

实际上，redo log并不是等到事务提交之后才写入的，而是一旦数据有修改，mysql就会把修改记录写入redo log日志文件中。那么问题来了，如果事务提交失败，那么数据不是会被改变吗？

2.undo log

（1）undo log文件正是用来保证事务回滚时，保证数据恢复的。undo日志有两个功能；一是可以保证事务可以进行回滚，而是实现多版本并发控制MVCC。现在主要是讨论一些undo日志是如何保证事务可以回滚的。

实际原理就是每更新一条数据，就生成一条相反的日志记录。比如insert语句，就生产相反的delete日志。当要回滚时，执行该语句即可。因此：undo保证了事务的原子性

所以，即使redo日志中，即使事务提交失败，但是数据记录以及更新，还是会通过undo日志修改回原来的状态

（2）文件位置

        位于ibdata文件中，该文件与ib_logfile同级

（3）什么时候产生undo log

事务一旦开始，就会产生undo log。另外，生成undo log的同时也会生成redo log来保证undo log的可靠性。但是注意：并不是事务一旦提交就会把undo log删除，而是会放入待清理链表，等待一个叫purge的线程判断是否可以删除（还要考虑MVCC的版本链问题）

3.bin log

        （1）该文件是一个二进制文件，主要作用是将事务中的sql语句全部记录在日志文件中。与redo日志不同的是，bin log是事务提交的时候把事务中的sql语句一次性写入到该日志文件中的。另外bin log是数据库层面的，而redo是事务层面的（保证事务的持久性）。bin log存的就是事务中的所有sql语句（二进制格式）。因此，bin log可以用来作数据恢复

4.另外，还有一个很重要的日志文件是error日志。该文件记录mysql的启动与停止以及运行过程中的错误信息，文件默认的位置默认也是与ib_logfilg文件同级别

最后：附上后端技术交流圈，欢迎各位大佬入圈交流技术......V:ff1341658（先添加好友后拉群，添加好友时请备注：小白不黑）