mysql如何查看事务日记_MYSQL中的事务日志

MYSQL日志

分类：

redo log

undo log

binlog

redo log

redolog是持久化在磁盘上的日志文件，记录的是对物理磁盘上数据的修改。

当数据发生修改时，innodb引擎会将记录写到redo log文件中，并更新内存，此时更新就算完成了，同时innodb引擎会在合适的时机记录操作到磁盘中。

redo log 是固定大小的，是循环写过程。

有了redo log之后，innodb 就可以保证数据库即使宕机、发生异常，之前的记录也不会丢失。

用来保证事务的持久性

为什么要引入redo log日志？

MySQL支持用户自定义在commit时如何将log buffer中的日志刷log file中。这种控制通过变量 innodb_flush_log_at_trx_commit 的值来决定。该变量有3种值：0、1、2，默认为1。但注意，这个变量只是控制commit动作是否刷新log buffer到磁盘。

当设置为1的时候，事务每次提交都会将log buffer中的日志写入os buffer并调用fsync()(同步写)刷到log file on disk中。这种方式即使系统崩溃也不会丢失任何数据，- 但是因为每次提交都会进行一次IO操作，IO性能较差，频繁调用IO太影响性能。

当设置为2的时候，每次提交都仅写入到os buffer，然后是每秒调用fsync()将os buffer中的日志写入到磁盘，当系统崩溃时，数据也只写入了os buffer，数据会丢失。

当设置为0的时候，事务提交时就将对应的操作写入redo log buffer(而redo log是持久化在磁盘上的)，然后每秒调用fsync()(同步写)将数据刷新到磁盘上，这样即使系统崩溃，数据也不会丢失，数据仍保留在redo log中。

注意：当设置为0的时候秒级调用fsync()将数据写入磁盘，这时批量操作，而设置为1是，是每次数据修改都将数据写入磁盘，是单次操作。

疑问

既然redo log是将数据持久化到磁盘上，那么必然也对应一次IO操作，那么每次修改数据直接将其刷新到磁盘的话，也是一次IO操作，按道理说效率应该一样低下，那么为什么还要引入redo log？

事实上，redo log写入文件尾是顺序写过程，虽然也是一次IO操作但磁头不需要移动。而每次都将数据更新到磁盘其实是将 buffer pool中的数据缓存页写入磁盘的数据也中，其中涉及到要寻找数据页在哪的操作，这是一个随机写过程，需要移动磁头，磁盘的随机写过程更耗时，耗资源，因此引入redo log是很有必要的。

undo log

undo log用来实现事务的原子性，在innnodb引擎中还用来实现事务的多版本并发控制

在操作数据库之前先将数据备份到一个地方，这个存储数据备份的地方就是undo log。然后再进行数据的修改，如果中途发生错误或者用户执行的rollback语句，系统利用undo log中的备份将数据回复到事务开始前的状态

redo log 是逻辑日志，可以理解为

当delect一条语句时，undo log 中会记录一条对应的insert语句

当insert一条语句时，undo log 中会记录一条对应的delect语句

当update一条语句时，undo log 中会记录一条相反的update语句

binlog

binlog是server层的日志，主要做mysql功能层的事情

binlog会记录所有的逻辑，并采用追加写的方式

一般企业中数据库会有备份系统，可以定期执行备份

利用binlog进行数据恢复

找到最近一次的全量备份数据

从备份的时间点将binlog取出来，重放到要恢复的时刻

binlog与redolog 的区别

redo log 是innodb引擎特有的，而binlog是所有存储引擎都可以使用的

redo log是物理日志，记录的是某页上具体的做的修改。binlog是逻辑日志，记录的是这个语句的原始逻辑。

redo log是循环写过程，空间有限，空间不够时会覆盖之前的信息。binlog是追加写过程不会覆盖之前的信息。