Mysql核心日志（redolog、undolog、binlog）

Binlog是MySQL事务日志的归档日志，记录了数据库中所有改变数据、表结构、索引等的操作。
Binlog以事件的形式记录，不仅记录流程数据，还记录执行所花费的时间。
Binlog有三种日志格式：ROW、STATMENT、MIXED。
ROW格式基于更改数据行的记录。
STATEMENT格式基于SQL语句级别记录。
MIXED格式是ROW和STATMENT的组合，通常用于事务处理。
binlog是在事务执行时写入的，具体策略由sync_binlog参数决定，包括不写盘、立即写盘、或者累积多个事务后再写盘。

Redolog是一个引擎层注册表（innodb）。
设计目标是支持事务的ACID属性，即原子性、一致性、隔离性和持久性。
Redolog确保传输事务引起的数据变化即使在系统宕机时也能通过返回数据来实现数据一致性，解决异常和停机可能导致的数据错误或丢失问题。
Redolog记录进程数据变化的历史，记录到磁盘的最小单位“页”，保证数据的原子性，避免数据库崩溃时出现部分数据成功、部分数据失败的情况。
Redolog的写入策略有不写磁盘、直接写磁盘、或者先写到缓冲区，然后根据限制决定是直接写磁盘还是当缓冲区达到一定占用率时再写磁盘。

undolog也是引擎层注册表（innodb），与redolog一起保证事务的原子性和持久性。
Undolog保存数据的历史版本，用于事务恢复和MVCC（多版本并发控制）功能。
在进行数据修改之前，undo会记录修改前数据的版本，并通过事务ID进行回滚。
undolog日志的内容包括进程的事务事务ID、数据修改前的版本、数据修改后的事务版本号和DB_ROLL_PTR地址。

redo、undo、binlog的创建过程和故障恢复机制如下：

执行刷新操作时，过程包括读取、undo记录、redo记录（pre-commit状态）），修改内存数据，并记录binlog，提交事务并写入redolog（提交状态）。
如果数据库在任何时候崩溃，恢复要看情况：1、第1到3步数据库崩溃了，不需要任何操作，因为数据没有改变。
2、第四步修改内存数据时崩溃，通过undo恢复数据。
3、写入binlog时第5步崩溃。
使用与第四步相同的逻辑来执行数据检索过程。
4、执行第6步发送事务时崩溃，事务可能已部分发送到二进制日志，但未完全发送。
应根据日志的状态确定恢复策略。
如果binlog中有事务记录，则会基于relogging来重构数据，避免父子数据不一致。
如果binlog中没有事务记录，则进行数据回滚。

mysql的日志有哪几类,作用是什么

MySQL日志大致分为四类：错误日志、查询日志、慢查询日志和二进制日志。
这些日志在数据库管理和优化中发挥着重要作用。
首先，错误日志记录MySQL服务器启动、运行或停止时出现的问题。
是否是服务器本身的问题、连接问题、权限问题等等，都会在错误日志中反映出来。
例如，如果用户尝试使用不存在的用户名登录，则此不正确的行为将记录在错误日志中。
通过分析这些日志，管理员可以快速发现并解决问题，保证数据库的稳定运行。
其次，查询日志记录数据库服务器接收到的所有SQL查询。
这包括来自客户端的连接和断开连接信息以及该期间执行的所有SQL语句。
查询日志对于分析和审核数据库活动非常有用，包括识别未经授权的查询或修改。
但由于查询日志记录了所有的操作，高并发系统可能会产生大量的日志数据，这可能会对性能产生一定的影响。
另外，慢查询日志专门记录执行时间超过设定阈值的SQL查询。
该阈值可通过“long_query_time”参数进行配置。
慢查询日志是数据库性能调优的强大工具，可以帮助开发人员和管理员发现可能导致性能瓶颈的复杂或低效查询。
例如，如果慢查询日志中频繁出现复杂的联表查询，开发人员就应该考虑查询优化，例如添加索引或修改查询逻辑。
最后，二进制日志记录所有修改数据库表结构或数据的语句，并以事件的形式存储。
由于这些事件描述了数据更改过程，因此二进制日志通常用于数据恢复和主从复制。
在主从复制场景中，主服务器上的更改会写入二进制日志，从服务器读取该日志并应用相同的更改以保持数据一致性。
另外，如果数据库发生故障，管理员可以利用二进制日志恢复到特定时间点，将数据恢复到故障前的状态。