能不能被耐久化到磁盘呢 Redolog 字节一面 事务还没提交的时刻

又是被自己菜醒的一天，总结面经看到这标题听都没听过，关上百度就像吃饭一样自然

老规矩，背诵版在文末。点击浏览原文可以中转我收录整顿的各大厂面试真题

首先，咱须要明确的是，啥是耐久化?

听起来矮小上，换句便捷的话来说，就是把数据写到磁盘上，也成为落盘。

那为啥要做耐久化到磁盘?

目标就是可以在数据失落后启动复原，保障数据不失落。

那么关于 MySQL 来说，只需 binlog 和 redolog 都能正确耐久化到磁盘上，就可以保障数据不失落了。

由此引出文题，不过在讲 redolog 之前，咱们还是有必要先来说一下 binlog 的耐久化操作。

binlog 耐久化

这里引入了一个新的概念：binlog cache

从名字就能看进去，binlog cache 其实就是一片内存区域，充任缓存的作用。

每个线程都有自己 binlog cache 区域，在事务运转的环节中，MySQL 会先把日志写到 binlog cache中，等到事务真正提交的时刻，再一致把 binlog cache 中的数据写到 binlog 文件中。(binlog cache 有很多个，binlog文件只要一个!)

理想上，这个从 binlog cache 写到 binlog 文件中的操作，并不就是落盘操作了，这里仅仅是把 binlog 写到了文件系统的 pagecache 上(这一步对应下图中的 write 操作)。

便捷解释下文件系统的 page cache：

CPU假设要访问外部磁盘上的文件，须要首先将这些文件的内容拷贝到内存中，由于配件的限度，从磁盘到内存的数据传输速度是很慢的，假设如今物理内存有空余，干嘛不用这些闲暇内存来缓存一些磁盘的文件内容呢，这部分用作缓存磁盘文件的内存就叫做page cache。

很多同窗看到这里或许感觉特意特意相熟，是的，和 CPU 里的高速缓存是不是很像?两者其实都是应用的部分性原理，只不过高速缓存是 CPU 缓存内存的数据，而page cache 是内存缓存磁盘的数据，这也表现了操作系统内存档次结构分级的思维。

所以，最后须要把 page cache 中的数据同步到磁盘上，才算真正成功了 binlog 的耐久化(这一步对应下图中的 fsync操作)。普通状况下，咱们以为 fsync 才占磁盘的 IOPS (Input/Output Operations Per Second)

write 和 fsync 的机遇，是由参数 sync_binlog 控制的：

可以看进去，假设业务场景触及到的 IO 操作很多的话，可以适当增大 sync_binlog 的值，提高性能。然而也存在肯定的危险，比如你设置成100，万一在第 80 个事务提交的时刻数据库宕机了，那这些事务的 binlog 日志由于没有口头 fsync，也就失落了。

redolog 耐久化

类比 binlog，在事务口头环节中，binlog 都是存在 binlog cache 中，redolog 也有这样一块内存区域，叫作 redologbuffer。

在事务运转的环节中，MySQL 会先把日志写到 redolog buffer 中，等到事务真正提交的时刻，再一致把 redolog buffer中的数据写到 redolog 文件中。和 binlog 的落盘操作一样，这个从 redolog buffer 写到 redolog文件中的操作，并不就是落盘操作了，这里仅仅是把 redolog 写到了文件系统的 page cache 上，最后还须要口头 fsync能力够成功真正的落盘。

解释下 redo log buffer?

在一个事务的降级环节中，日志是要写屡次的。比如上方这个事务：

这个事务要往两个表 table1 和 table2中拔出记载，为了确保这个事务不被拆开，一次性性的完整写入日志文件中，在拔出数据的环节中，咱们须要把生成的日志都先保留起来。redolog buffer就是这么一个用来先存 redo 日志的中央。

也就是说，在口头第一条 insert 语句的时刻，redolog buffer 也就写入了这条记载的日志。

不同于 binlog cache 每个线程都有一个，redolog buffer 只要那么一个。

理想上，日志写到 redolog buffer 是很快的，wirte 到 page cache 也差不多，然而 fsync耐久化到磁盘的速度就慢多了，为了控制 redo log 的写入战略，InnoDB 提供了 innodb_flush_log_at_trx_commit参数，它有三种或许取值：

先说答案，答案就是有或许。

剖析下 redolog 或许存在的三种形态(binlog 也差不多)：

至于为什么说事务还没提交的时刻，redolog 也有或许被耐久化到磁盘呢?

InnoDB 有一个后盾线程，每隔 1 秒轮询一次性，详细的操作是这样的：调用 write 将 redolog buffer 中的日志写到文件系统的page cache，而后调用 fsync 耐久化到磁盘。而在事务口头两边环节的 redolog 都是间接写在 redolog buffer中的，也就是说，一个没有提交的事务的 redolog，也是有或许会被后盾线程一同耐久化到磁盘的。

另外，除了后盾线程每秒一次性的轮询操作外，还有两种场景会让一个没有提交的事务的 redolog 写盘：

举个例子，假定事务 A 口头到一半，曾经写了一些 redolog 到 redolog buffer 中，这时刻有另外一个事务 B 提交，依照innodb_flush_log_at_trx_commit = 1 的逻辑，事务 B 要把 redolog buffer里的日志所有耐久化到磁盘，这时刻，就会带上事务 A 在 redolog buffer 里的日志一同耐久化到磁盘

最后放上这道题的背诵版：

关系疑问：MySQL 是如何保障数据不失落的呢?

小牛肉：事务还没有提交的时刻，redo log 是有或许被耐久化到磁盘的。

redolog 的详细落盘操作是这样的：在事务运转的环节中，MySQL 会先把日志写到 redolog buffer 中，等到事务真正提交的时刻，再一致把redolog buffer 中的数据写到 redolog 文件中。不过这个从 redolog buffer 写到 redolog 文件中的操作也就是write 并不就是落盘操作了，这里仅仅是把 redolog 写到了文件系统的 page cache 上，最后还须要口头 fsync能力够成功真正的落盘。

也就是说，redolog 其实存在三种形态：

额为什么说事务还没提交的时刻，redolog 也有或许被耐久化到磁盘呢?

重要有三种或许的要素：