今天给大家分享MySQL中的三种核心日志——Redo Log、Undo Log和Binlog，涵盖它们的介绍、作用、存储位置、写入机制、记录格式、特点以及如何管理这些日志。
1. Redo Log（重做日志）1.1 介绍与作用Redo Log记录了对InnoDB存储引擎中数据页修改的物理操作。它的主要目的是确保事务的持久性，即使在系统崩溃时也能保证数据不丢失。当事务提交时，其相关更改首先被记录到Redo Log中，随后才会标记事务状态为已提交。
1.2 默认存储位置Redo Log存储在MySQL的数据目录下的`ib_logfile*`文件中，如`/var/lib/mysql/ib_logfile0`和`ib_logfile1`。
1.3 写入机制Redo Log采用循环写的方式，当一个日志文件写满后会切换到下一个日志文件继续写入。事务提交时，相关日志会立即写入磁盘（即使事务尚未完成），这称为“预写式日志”（Write-Ahead Logging, WAL）策略。
1.4 记录格式Redo Log记录的是物理日志，即实际对数据页做的修改操作。
1.5 特点● 确保事务的持久性。
● 支持崩溃恢复，通过重做已记录的操作来恢复数据。
1.6 如何删除Redo Log是循环使用的，不需要手动删除。MySQL会自动管理这些日志文件，旧的日志在新的日志被写满并确认不再需要时会被覆盖。
2. Undo Log（回滚日志）2.1 介绍与作用Undo Log主要用于事务的回滚操作，记录了如何撤销对数据库的修改，以实现事务的原子性。当事务需要回滚时，Undo Log能帮助恢复到事务开始前的状态。
2.2 存储位置Undo Log存储于InnoDB表空间内，具体位置依赖于表空间配置，一般位于ibdata文件或自定义的表空间文件中。
2.3 写入机制Undo Log同样采用预写日志方式，事务开始时写入Undo Log，事务提交或回滚后可能会被清理。
2.4 记录格式Undo Log记录的是逻辑日志，描述了如何反向操作以撤销更改。
2.5 特点● 支持事务的原子性，允许回滚操作。
● 在MVCC（多版本并发控制）中，用于提供历史版本数据。
2.6如何删除Undo Log在事务提交且不再需要时会被自动清理，或者在表空间不足时按照一定的策略进行回收。
3. Binlog（二进制日志）3.1 介绍与作用Binlog记录了MySQL服务器上执行的所有更改数据SQL语句（除了数据查询语句）。它主要用于数据恢复、主从复制以及数据审计。
3.2 存储位置Binlog文件默认存储在MySQL的数据目录下（/var/lib/mysql），文件名格式为`mysql-bin.*`。
3.3 写入机制Binlog采用追加写的方式，新事件不断被添加到日志文件末尾。MySQL支持多种写入模式，包括ROW（记录每一行的变化）、STATEMENT（记录执行的SQL语句）和MIXED（根据情况自动选择ROW或STATEMENT）。
说明：需要开启Binlog日志，才会写入，开启方法一般修改mysql.ini(Windows)和my.cnf配置文件。
3.4 记录格式Binlog记录的是逻辑日志，根据设置的不同，可以是SQL语句的文本或是行级别的变化。
日志格式
记录内容
Statement
记录进行数据修改 SQL 语句。
Row
记录每一行的数据变更，占用较多空间。（默认）
Mixed
前两者混合，判断是否可能引起数据不一致：可能则用Row 否则用Statement
3.5 特点● 支持数据恢复和复制。
● 对于主从复制，是同步数据的关键。
● 可用于审计和数据变更跟踪。
3.6 如何删除可以通过`PURGE BINARY LOGS`命令手动删除指定的或过期的Binlog文件,或者使用reset 删除全部日志（慎用）
指令
含义
reset master
删除全部日志
purge master logs to 'binlog.xxx'
删除xxx编号之前的日志
purge master logs before 'yyyy-mm-dd hh:mm:ss'
删除引号时间之前产生的日志
show variables like '%binlog_expire_logs_seconds%';
配置日志过期时间，到期自动删除
总的来说，Redo Log、Undo Log和Binlog各自承担着不同的职责，共同维护着MySQL数据库的稳定运行和数据一致性。理解这些日志的工作原理对于数据库管理和优化至关重要。
