MySQL中的日志（redo log、undo log、binlog）
文章目录
MySQL中的日志
一般日志
Mysql 中的日志主要包括：
1、慢查询日志：记录执行时间超过long_query_time的所有查询，方便我们对查询优化
2、通用查询：日志:记录所有连接的起始时间和终止时间，以及连接发送给数据库服务器的所有指令,对我们复原操作的实际场景、发现问题，甚至是对数据库操作的审计都有很大的帮助。
3、查询日志：错误日志:记录MySQL服务的启动、运行或停止MySQL服务时出现的问题,方便我们了解服务器的状态，从而对服务器进行维护。
4、二进制日志（bin log）：记录所有更改数据的语句，可以用于主从服务器之间的数据同步，以吸服务器遇到故障时数据的无损失恢复。
5、中继日志：用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。
6、数据定义语句日志：记录数据定义语句执行的元数据操作。
binlog（Binary Log）：
二进制日志文件就是常说的binlog。二进制日志记录了MySQL所有修改数据库的操作，然后以二进制的形式记录在日志文件中，其中还包括每条语句所执行的时间和所消耗的资源，以及相关的事务信息。
默认情况下，二进制日志功能是开启的，启动时可以重新配置 --log-bin[=file_name] 选项，修改二进制日志存放的目录和文件名称。
重做日志
重做日志用来实现事务的持久性，即事务ACID中的D。
它由两部分组成：
- 一是内存中的重做日志缓冲（redo log buffer），其是易失的；
- 二是重做日志文件（redo log file），它是持久的。
InnoDB是事务的存储引擎，它通过Force Log at Commit机制实现事务的持久性，即当事务提交（COMMIT）时，必须先将该事务的所有日志写入到重做日志文件进行持久化，待事务的COMMIT操作完成才算完成。
这里的日志是指重做日志，在InnoDB存储引擎中，由两部分组成，即redo log和undo log。
重做日志记录了事务的行为，可以很好地通过其对页进行“重做”操作。但是事务有时还需要进行回滚操作，这时就需要undo。
因此在对数据库进行修改时，InnoDB存储引擎不但会产生redo，还会产生一定量的undo。这样如果用户执行的事务或语句由于某种原因失败了，又或者用户用一条ROLLBACK语句请求回滚，就可以利用这些undo信息将数据回滚到修改之前的样子。
redo log 与 undo log概念
redo log
redo log 称为重做日志 ，是储存引擎层（innodb）生成的日志。
提供再写入的操作，回复提交事务修改页的操作，用来保证事务持久性，假如说发生宕机，可以进行恢复数据，保证持久性。他记录的是“物理级别”上的页修改操作，比如页号x，偏移量y，写入了“”ds‘’数据。为了保证数据的可靠性；
undo log
undo log 称为回滚日志，也是是储存引擎层（innodb）生成的日志。
回滚记录到某个特定的版本，用来保证事务原子性，一致性。主要用于事物的回滚 和 一致性非锁定读（undo log 会滚到记录某种特定的版本—mvcc，也就是多版本并发控制）。
redo log 与 undo log区别
redo存放在重做日志文件中，与redo不同，undo存放在数据库内部的一个特殊段（segment）中，这个段称为undo段（undo segment），undo段位于共享表空间内。
redo log用来保证事务的持久性，undo log用来帮助事务回滚及MVCC的功能。
redo log基本上都是顺序写的，在数据库运行时不需要对redo log的文件进行读取操作。而undo log是需要进行随机读写的。
redo log 与 undo log原理
redo log
redo log 的作用主要是实现 ACID 中的持久性，保证提交的数据不丢失
- 它记录了事务提交的变更操作，服务器意外宕机重启时，利用 redo log 进行回放，重新执行已提交的变更操作
- 事务提交时，首先将变更写入 redo log，事务就视为成功。至于数据页（表、索引）上的变更，可以放在后面慢慢做
- 数据页上的变更宕机丢失也没事，因为 redo log 里已经记录了
- 数据页在磁盘上位置随机，写入速度慢，redo log 的写入是顺序的速度快
它由两部分组成，内存中的 redo log buffer，磁盘上的 redo log file
redo log file由一组文件组成，当写满了会循环覆盖较旧的日志，这意味着不能无限依赖 redo log，更早的数据恢复需要 binlogbuffer 和 file两部分组成意味着，写入了文件才真正安全，同步策略由参数innodb_flush_log_at_trx_commit控制，同步策略如下：
| 策略参数 | 说明 |
0 |
每隔 1s 将日志 write and flush 到磁盘 |
1 |
每次事务提交将日志 write and flush（默认值） |
2 |
每次事务提交将日志 write，每隔 1s flush 到磁盘，意味着 write 意味着写入操作系统缓存，如果 MySQL 挂了，而操作系统没挂，那么数据不会丢失 |
undo log
- 回滚数据，以行为单位，记录数据每次的变更，一行记录有多个版本并存
- 支持多版本并发控制（MVCC），即快照读（也称为一致性读），让查询操作可以去访问历史版本
回滚流程如何如下所示：
- 每个事务会按照开始时间，分配一个单调递增的事务编号 trx id
- 每次事务的改动都会以行为单位记入回滚日志，包括当时的事务编号，改动的值等
- 查询操作，事务编号大于自己的数据是不可见的，事务编号小于等于自己的数据才是可见的
- 例如图中红色事务看不到 trx id=102 以及 trx id=101 的数据，只有 trx id=99 的数据对它可见
