【MySQL】-日志系统

一、背景介绍

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 f）中配置

使用场景： 预热数据、过大文件、日志记录、延迟加载数据（同步）

---

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的执行流程、内存和磁盘的过渡等微观去详细了解，宏观到微观。

参考博客

blog.csdn.net/J080624/article/details/128591262

如果有想要交流的内容欢迎在评论区进行留言，如果这篇文档受到了您的喜欢那就留下你点赞+收藏+评论脚印支持一下博主~