MySQL中的redo log和undo log

最新推荐文章于 2024-05-29 17:07:22 发布

pedro7k

最新推荐文章于 2024-05-29 17:07:22 发布

阅读量947

点赞数 1

文章标签： mysql

本文链接：https://blog.csdn.net/pedro7k/article/details/119110412

版权

MySQL日志系统中最重要的日志为重做日志redo log和归档日志bin log，后者为MySQL Server层的日志，前者为InnoDB存储引擎层的日志。

redo log用于保证事务的持久性，即ACID中的D。

持久性：指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

redo log有两种类型，分别为物理重做日志和逻辑重做日志。在InnoDB中redo log大多数情况下是一个物理日志，记录数据页面的物理变化（实际的数据值）。

redo log的主要功能是用于数据库崩溃时的数据恢复。

redo log可以分为以下两部分

以更新事务为例。

Force Log at Commit机制实现了事务的持久性。在内存中操作时，日志被写入重做日志缓冲区。但在事务提交之前，必须首先将所有日志写入磁盘上的重做日志文件。

为了确保每个日志都写入重做日志文件，必须使用一个fsync系统调用，确保OS buffer中的日志被完整地写入磁盘上的log file。

fsync系统调用：需要你在入参的位置上传递给他一个fd，然后系统调用就会对这个fd指向的文件起作用。fsync会确保一直到写磁盘操作结束才会返回，所以当你的程序使用这个函数并且它成功返回时，就说明数据肯定已经安全的落盘了。所以fsync适合数据库这种程序。

InnoDB提供了一个参数innodb_flush_log_at_trx_commit控制日志刷新到磁盘的策略。

**当innodb_flush_log_at_trx_commit值为1时（默认）。**事务每次提交都必须将log buffer中的日志写入os buffer并调用fsync()写入磁盘中。
- 这种方式即使系统崩溃也不会丢失任何数据，但是因为每次提交都写入磁盘，IO性能较差。
**当innodb_flush_log_at_trx_commit值为0时。**事务提交时不将log buffer写入到os buffer，而是每秒写入os buffer并调用fsync()写入到log file on disk中。
- 这实际上相当于在内存中维护了一个用户设计的缓冲区，它减少了和os buffer之间的数据传输，有更好的性能。
- 每秒写入磁盘，系统崩溃会丢失1s的数据。
**当innodb_flush_log_at_trx_commit值为2时。**每次提交都仅写入os buffer，然后每秒调用fsync()将os buffer中的日志写入到log file on disk中。
- 虽然说我们是每秒调用fsync()将os buffer中的日志写入到log file on disk中，但是平时即使不调用fsync，数据也会2自主地逐渐进入磁盘。所以当发生系统崩溃，相比第二种情况，会丢失较少的数据。
- 但同时，由于每次提交都写入os buffer，所以相比第二种情况，性能会差一些，但还是比第一种好的。
无论是哪种情况

几个选项之间的性能差距是极大的，下面做一个简单的测试。

#创建测试表
drop table if exists test_flush_log;
create table test_flush_log(id int,name char(50))engine=innodb;

#创建插入指定行数的记录到测试表中的存储过程
drop

关注