一，前言

MySQL实现事务、集群的主从复制，底层都离不开日志，所以日志是MySQL的精华所在。只有了解MySQL日志，才算是彻底搞懂MySQL
本文主要讲述MySQL的三大日志系统，Redo Log（重做日志）、Undo Log（恢复日志）、Bin Log（备份日志）

二，binlog-备份日志

1，作用

Bin Log记录的是逻辑日志，即原始的SQL语句，是MySQL自带的。
作用： 数据备份和主从同步。

2，使用场景

在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。

• 主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
• 数据恢复：通过使用mysqlbinlog工具来恢复数据。

3，日志形式

Bin Log共有三种日志格式，可以binlog_format配置参数指定

4，binlog刷盘时机

对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中，那么biglog是什么时候刷到磁盘中的呢？mysql通过sync_binlog参数控制biglog的刷盘时机，取值范围是0-N：

• 0：不去强制要求，由系统自行判断何时写入磁盘；
• 1：每次commit的时候都要将binlog写入磁盘；
• N：每N个事务，才会将binlog写入磁盘。

从上面可以看出，sync_binlog最安全的是设置是1，这也是MySQL 5.7.7之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。

三，redo log-重做日志

1，概念

redo log包括两部分：一个是内存中的日志缓冲(redo log buffer)，另一个是磁盘上的日志文件(redo log file)。mysql每执行一条DML语句，先将记录写入redo log buffer，后续某个时间点再一次性将多个操作记录写到redo log file。这种先写日志，再写磁盘的技术就是MySQL里经常说到的WAL(Write-Ahead Logging) 技术

2，为什么需要redo log

• 事务的四大特性里面有一个是持久性，具体就是只要事务提交成功，数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么mysql是如何保证持久性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中
• 但是这么做会有严重的性能问题，主要体现在两个方面：
  （1）因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了
  （2）一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机IO写入性能太差
• 因此mysql设计了redo log，具体来说就是只记录事务对数据页做了哪些修改

3，日志形式

redo log实际上记录数据页的变更，而这种变更记录是没必要全部保存，因此redo log实现上采用了大小固定，循环写入的方式，当写到结尾时，会回到开头循环写日志

4，redo log与binlog区别

四，undo log-回滚日志

1，undo log的内容和作用

undo log记录的是逻辑日志，也就是sql语句
比如：当我们执行一条insert语句时，Undo Log就记录一条相反的delete语句。
作用：

• 回滚事务时，恢复到修改前的数据。

• 实现 MVCC（多版本并发控制，Multi-Version Concurrency Control） 。

• MySQL事务中原子性就是使用Undo Log实现的。

2，mysql的日志

MySQL的日志（log）主要包括以下几种类型：

• 错误日志（Error Log）：记录MySQL服务器出现错误的信息，如非法用户连接、语法错误等。
• 二进制日志（Binary Log）：记录MySQL服务器执行的所有修改数据的操作语句，如INSERT、DELETE、UPDATE。
• 慢查询日志（Slow Query Log）：记录查询运行时间超过指定阈值（slow_query_log_threshold）的SQL语句。
• 查询日志（Query Log）：记录所有客户端与MySQL服务器交互的命令，包括查询和修改等操作。
• 事务日志（Transaction Log）：记录所有接收到的SQL语句，可以用于回滚和恢复。
• 中继日志（Relay Log）：主要用于MySQL的主从复制机制，用于将主服务器的二进制日志复制到从服务器上。
  以上就是MySQL的常用日志类型。