【数据库/MySQL】MySQL三大日志提要
MySQL三大日志
mysql常用日志
MySQL日志中比较重要的包括redo log（重做日志）、（归档日志）和undo log（回滚日志）。
redo log
The most for is the redo log, which of two or more files that store all made to the as they occur. Every of an has an redo log to the in case of an .
恢复操作的最关键结构是重做日志，该日志由两个或多个预关注的文件组成，这些文件存储在数据库中进行的所有更改。数据库的每个实例都有关联的重做日志，以保护实例失败的情况。
**redo log是物理日志，属于存储引擎。**为了应对各种各样不同的需求，到MySQL 8.0为止，已经有多达65种的REDO记录。用来记录这不同的信息，恢复时需要判断不同的REDO类型，来做对应的解析。根据REDO记录不同的作用对象，可以将这65中REDO划分为三个大类：作用于Page，作用于Space以及提供额外信息的Logic类型。
对于MySQL数据库，redo log是存储引擎独有的，提供了崩溃恢复能力。MySQL 实例挂了或宕机了，重启时存储引擎会使用redo log恢复数据，保证数据的持久性与完整性。
MySQL中数据以页为单位，查询记录加载出来的数据叫数据页，会放入到 pool中。后续查询先从 Pool中找，没有命中再到硬盘中加载，减少硬盘IO开销。
更新表数据的时候，也是如此，发现 Pool 里存在要更新的数据，就直接在 Pool 里更新。
然后会把“在某个数据页上做了什么修改”记录到重做日志缓存（redo log ）里，接着刷盘到 redo log 文件里。
刷盘时机
存储引擎为 redo log 的刷盘策略提供了 参数，它支持三种策略：
参数默认为 1 ，也就是说当事务提交时会调用 fsync 对 redo log 进行刷盘。
另外， 存储引擎有一个后台线程，每隔1 秒，就会把 redo log 中的内容写到文件系统缓存（page cache），然后调用 fsync 刷盘。
"挂了"和“宕机”：认为挂了是运行异常，应该还会把cache的存储进行刷盘；宕机可能是断电等，导致cache失效，存储丢失。
日志文件组
环形数组形式，从头开始写，写到末尾又回到头循环写。
为什么不直接刷盘
数据页大小是16KB，刷盘比较耗时，可能就修改了数据页里的几 Byte 数据，没有必要把完整的数据页刷盘。
数据页刷盘是随机写，因为一个数据页对应的位置可能在硬盘文件的随机位置，所以性能是很差。
所以用 redo log 形式记录修改内容，性能会远远超过刷数据页的方式，这也让数据库的并发能力更强。
bin log
bin log是逻辑日志，记录内容是语句的原始逻辑，属于MySQL 层。不管用什么存储引擎，发生数据更新都会产生bin log日志。
MySQL数据库的数据备份、主备、主主、主从都离不开，需要依靠来同步数据，保证数据一致性。
记录格式 写入机制
事务执行过程中，先把日志写到 cache，事务提交的时候，再把 cache写到文件中。
因为一个事务的不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为 cache。
write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快。
fsync，才是将数据持久化到磁盘的操作。
write和fsync的时机，可以由参数控制，默认是0。
两阶段提交
redo log（重做日志）让存储引擎拥有了崩溃恢复能力。
（归档日志）保证了MySQL集群架构的数据一致性。
两份日志可能逻辑不一致，导致恢复数据错误。为解决这一问题，存储引擎使用两阶段提交方案，将redo log的写入拆成两个步骤，和，两阶段提交。
undo log
概念：回滚日志，用来记录数据被修改前的信息。正好跟前面的重做日志进行相反操作。undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。回滚日志会先于数据持久化到磁盘上。这样就保证了即使遇到数据库突然宕机等情况，当用户再次启动数据库的时候，数据库还能够通过查询回滚日志来回滚将之前未完成的事务。
作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读；
内容：逻辑格式的日志，在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于 redo log 的。
另外，MVCC 的实现依赖于：隐藏字段、Read View、undo log。在内部实现中， 通过数据行的 和 Read View 来判断数据的可见性，如不可见，则通过数据行的 找到 undo log 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 Read View 之前已经提交的修改和该事务本身做的修改。
总结
主体主要参考自对应章节
中的总结：
MySQL 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。
MySQL数据库的数据备份、主备、主主、主从都离不开，需要依靠来同步数据，保证数据一致性。
