一、背景介绍
MySQL中提供了各种各样的日志，每一个日志在不同的阶段有不同的作用，对数据的一致性和正确性得到保障，为数据恢复也提供至关重要的作用，那今天我们一起来讨论讨论MySQL中的各个日志
二、正文
binlog：二进制日志，默认不开启
作用：
记录所有执行的DDL和DML语句（除了select、show等），便于数据同步以及恢复，哪怕数据丢失也能找到
归属：
mysql的server层
存储位置：
/etc/mysql/mysql.conf.d/
如何开启binlog日志记录？
可以在配置文件中添加或修改以下参数来开启binlog日志
errorlog：错误日志
作用：
操作出错放在这儿，能够帮助定位MySQL问题
slowlog：慢查询日志
作用：
给数据库的sql语句设置一个预期执行时间（long_query_time，单位：秒，默认10秒），当sql语句的执行时间超过了预期时间则把这条SQL语句的相关信息记录到慢查询日志中，方便定位哪些查询语句的执行效率低便于后期优化
记录内容：
- 长时间运行的查询：如果一条查询花费大量时间来完成，那么它可能存在性能问题
- 高I/O消耗的查询：当查询需要从磁盘上获取大量数据时，它可能对系统造成不必要的负载
- 未使用索引的查询：没有正确地利用索引将导致全表扫描，效率较低 重复查询：同样的查询多次执行也可能是性能问题的原因之一
- 错误配置的查询参数：如果查询参数设置不合理，比如内存限制、连接池等，都可能导致查询变得更加缓慢
如何开启慢查询日志？
查询是否开启慢查询日志
MySQL默认是没有开启慢查询日志，需要在（/et/my.cnf）中配置
使用场景：
预热数据、过大文件、日志记录、延迟加载数据（同步）
relaylog：中继日志
作用：
在进行主从复制的过程中，需要把主服务器的binlog文件内容同步到从服务的relaylog日志从而保持主从服务器的数据一致性。从服务器读取relaylog中的记录并对数据进行更新
归属：
从服务器
undolog：回滚日志
作用：
记录事务的insert、update、delete操作，记录历史版本的数据，编写的sql语句会生成相反的操作，比方说事务在执行insert语句的时候日志会记录delete，这样的好处是当事务执行失败或者要回滚时，能够快速利用undolog中的信息将数据回滚到修改前的状态
归属：
innodb存储引擎内部
redolog：前滚日志
作用：
当数据被修改时，所有的修改会先写入到redolog日志中，在更新到Buffer Pool，保证了数据不会因为一些外部原因（如：MySQL宕机）而导致数据丢失；当事务在提交的时候，将redolog进行刷盘，如果Mysql宕机或者重启时也可以读取redolog中的数据，从而对数据进行恢复
归属：
innodb存储引擎内部
内存写磁盘的时候是随机读写的，而由内存写入redolog再写入磁盘的过程是append追加的方式顺序读写的，可以通过redolog机制恢复数据，也叫write ahead log
在前文中讲binlog日志时当进行DDL和DML语句时会写入记录到日志文件，修改数据时会写入记录到redolog日志，屏幕前的你思考一个问题：binlog和redolog同时都会记录数据，那如何保证文件中数据的一致性呢？
这就引申出了两阶段提交的概念
两阶段提交
什么时两阶段提交？
将redo log的写入拆成了两个步骤prepare 和commit，这就是两阶段提交
当修改数据时：
先写入redolog日志，给redolog添加一个prepare状态
写入binlog日志
再写redolog，修改状态为commit
数据恢复时：
读取redolog，发现状态为prepare，处于prepare状态的数据是不能用的，
于是读取binlog，查看binlog有没有与之相匹配的数据：
没有，把redolog这条数据删除掉，回顾记录
有，自动把redolog的状态改成commit，更新数据
三、总结
针对各个日志做了简单的介绍，内部更为细节的内容还需要我们结合MySQL的执行流程、内存和磁盘的过渡等微观去详细了解，宏观到微观。
参考博客
https://blog.csdn.net/J080624/article/details/128591262
