Mysql三大日志

MySQL 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）。

redo log

考点：刷盘时机、存储形式。

作用：是InnoDB存储引擎独有的，它让Mysql拥有了崩溃恢复能力。

binlog

redo log 是物理日志，记录内容是”在某个数据页上做了什么修改“，属于InnoDB存储引擎。

binlog是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server 层。

应用场景：MySQL数据库的数据备份、主备、主主、主从。（依靠binlog来同步数据，保证数据的一致性）

记录格式

binlog日志有三种格式，通过binlog_format参数指定。

• statement
• row
• mixed

statement 记录：SQL语句原文。

存在问题：如果SQL原文中是update_time = now()，获取当前系统时间，直接执行会导致与原库的数据不一致。

解决方案：row，记录：原始SQL语句 + 具体数据。

例如

其中，row格式记录的内容看不到原始信息，要通过mysqlbinlog工具解析出来。条件后面的@1、@2、@3 都是该行数据第 1 个~3 个字段的原始值。

存在问题：需要大量的容量来记录，比较占用空间，恢复与同步时会更消耗IO资源，影响执行速度。

折中方案：mixed，记录的内容是前两者的混合。

判断条件：这条SQL语句是否会引起数据不一致，如果是，就用row格式，否则就用statement格式。

写入机制

事务的执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binglog文件中。

binlog日志刷盘流程

两阶段提交

redo log（重做日志）让 InnoDB 存储引擎拥有了崩溃恢复能力。

binlog（归档日志）保证了 MySQL 集群架构的数据一致性。

undo log

每一个事务对数据的修改都会被记录到 undo log ，当执行事务过程中出现错误或者需要执行回滚操作的话，MySQL 可以利用 undo log 将数据恢复到事务开始之前的状态。

undo log 属于逻辑日志，记录的是 SQL 语句，比如说事务执行一条 DELETE 语句，那 undo log 就会记录一条相对应的 INSERT 语句。同时，undo log 的信息也会被记录到 redo log 中，因为 undo log 也要实现持久性保护。并且，undo-log 本身是会被删除清理的，例如 INSERT 操作，在事务提交之后就可以清除掉了；UPDATE/DELETE 操作在事务提交不会立即删除，会加入 history list，由后台线程 purge 进行清理。

另外，MVCC 的实现依赖于：隐藏字段、Read View、undo log。在内部实现中，InnoDB 通过数据行的 DB_TRX_ID 和 Read View 来判断数据的可见性，如不可见，则通过数据行的 DB_ROLL_PTR 找到 undo log 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 Read View 之前已经提交的修改和该事务本身做的修改。

总结：

MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。

MySQL 数据库的数据备份、主备、主主、主从都离不开 binlog，需要依靠 binlog 来同步数据，保证数据一致性。