MySQL日志详解

淡淡的烟草味﹌ 2021-09-21 05:08 293阅读 0赞

MySQL 常见的七种日志文件，  
分别是：**重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。**

其中

*  重做日志和回滚日志与事务操作息息相关，
 *  二进制日志也与中继日志通常用于主从复制
 *  错误日志是记录数据库故常
 *  慢查询日志经常用于数据库性能调优

### 一、主从复制的过程（二进制日志和中继日志） ###

1.在每个事务更新数据完成之前，master 在二进制日志记录这些改变。写入二进制日志完成后，master 通知存储引擎提交事务。

2.Slave 将 master 的 binary log 复制到其中继日志。首先 slave 开始一个工作线程（I/O），I/O 线程在 master 上打开一个普通的连接，然后开始 binlog dump process。binlog dump process 从 master 的二进制日志中读取事件，如果已经跟上 master，它会睡眠并等待 master 产生新的事件，I/O 线程将这些事件写入中继日志。

3.Sql slave thread（sql 从线程）处理该过程的最后一步，sql 线程从中继日志读取事件，并重放其中的事件而更新 slave 数据，使其与 master 中的数据一致，只要该线程与 I/O 线程保持一致，中继日志通常会位于 os 缓存中，所以中继日志的开销很小。

--------------------

### 二、重做日志（redo log） ###

1.作用：

*  确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启 mysql 服务的时候，根据 redo log 进行重做，从而达到事务的持久性这一特性。

2.内容：

*  物理格式的日志，记录的是物理数据页面的修改的信息，其 redo log 是顺序写入 redo log file 的物理文件中去的。

3.什么时候产生：

*  事务开始之后就产生 redo log，redo log 的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入 redo log 文件中。

4.什么时候释放：

*  当对应事务的脏页写入到磁盘之后，redo log 的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

--------------------

### 三、回滚日志（undo log） ###

1.作用：

*  保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读

2.内容：

*  逻辑格式的日志，在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于 redo log 的。

3.什么时候产生：

*  事务开始之前，将当前是的版本生成 undo log，undo 也会产生 redo 来保证 undo log 的可靠性

4.什么时候释放：

*  当事务提交之后，undo log 并不能立马被删除，
 *  而是放入待清理的链表，由 purge 线程判断是否由其他事务在使用 undo 段中表的上一个事务之前的版本信息，决定是否可以清理 undo log 的日志空间。

--------------------

### 四、慢查询日志 ###

1.定义：

*  MySQL 默认设置 10s 没有返回结果的，属于慢查询，并存到日志中 (在 my.ini 可以指定慢查询日志目录).

2.开启慢查询

*  slow\_query\_log 慢查询开启状态。
 *  slow\_query\_log\_file 慢查询日志存放的位置（这个目录需要 MySQL 的运行帐号的可写权限，一般设置为 MySQL 的数据存放目录）。
 *  long\_query\_time 查询超过多少秒才记录。

以上三个参数可以在数据库的配置文件中设定开启，也可以在在 mysql命令行通过set命令开启。当在配置文件中开启慢查询日志记录之后，就会在指定的存放目录生成日志文件。

3.分析慢查询—explain

当我们获得慢查询的日志之后，查看日志，观察那些语句执行是慢查询，在该语句之前加上explain再次执行，explain 会在查询上设置一个标志，当执行查询时，这个标志会使其返回关于在执行计划中每一步的信息，而不是执行该语句。它会返回一行或多行信息，显示出执行该计划中的每一部分和执行次序.

--------------------

**五、补充：数据库的MVVC是什么？**

**MVCC 的全称是 “多版本并发控制”**。这项技术使得 InnoDB 的事务隔离级别下执行**一致性读操作**有了保证，换言之，就是为了**查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值**。这是一个可以用来增强并发性的强大的技术，因为这样的一来的话查询就不用等待另一个事务释放锁。MVVC依靠的是数据库的回滚日志。

mysql 的 innodb 采用的是行锁，而且采用了多版本并发控制来提高读操作的性能。**MVVC其实就是在每一行记录的后面增加两个隐藏列，记录创建版本号和删除版本号**，而每一个事务在启动的时候，都有一个唯一的递增的版本号。 在 InnoDB 中，给每行增加两个隐藏字段来实现 MVCC，两个列都用来存储事务的版本号，每开启一个新事务，事务的版本号就会递增。

**读取创建版本小于或等于当前事务版本号，并且删除版本为空或大于当前事务版本号的记录。这样可以保证在读取之前记录是存在的。**

**一致性非锁定读**

consistent read （一致性读），InnoDB 用多版本来提供查询数据库在某个时间点的快照。如果隔离级别是 REPEATABLE READ，那么在同一个事务中的所有一致性读都读的是事务中第一个这样的读读到的快照；如果是 READ COMMITTED，那么一个事务中的每一个一致性读都会读到它自己刷新的快照版本。Consistent read（一致性读）是 READ COMMITTED 和 REPEATABLE READ 隔离级别下普通 SELECT 语句默认的模式。一致性读不会给它所访问的表加任何形式的锁，因此其它事务可以同时并发的修改它们。

--------------------

**【Java 面试那点事】**

**这里致力于分享 Java 面试路上的各种知识，无论是技术还是经验，你需要的这里都有！**

**这里可以让你【快速了解 Java 相关知识】，并且【短时间在面试方面有跨越式提升】**

**面试路上，你不孤单！**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzOTQ1MjQ2_size_16_color_FFFFFF_t_70]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzOTQ1MjQ2_size_16_color_FFFFFF_t_70]: /images/20210920/5fe7270d039d4f7386de33d5f4d6c74a.png