【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.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，更新数据