2021-05-26 [MySQL] MySQL中的那些日志_2021 mysql 日志-CSDN博客

本文链接：https://blog.csdn.net/lzr_ps/article/details/117307444

Mysql中的那些日志

今天来聊聊mysql中的哪些日志

error log记录了mysql的启动、运行、关闭的一些信息，不仅是错误信息，错误日志也会记录一些警告信息或正确信息。

SHOW VARIABLES LIKE 'log_error';

定位错误日志。

bin log记录了所有对数据库进行更改的操作，主要的目的适用于复制和恢复。

只有提交的事务才会记录到binlog，而binlog刷新到磁盘跟sync_binlog参数有关，若为0，则不控制该刷新，若为n，则等到提交n次事务后才会刷新，一般设为1。

binlod有三种格式：基于sql语句的复制、基于行的复制、混合模式

慢查询日志记录了一些查询时间超过一定阈值的语句，我们可以定期的查看该日志，以便思考是否需要进行优化。

默认慢查询日志是关闭的，需要手动打开。

查询日志记录了所有对mysql数据库的请求，无论是否被正确的执行。

事务日志由innodb来提供，主要是为了实现事务的ACID原则，即原子性、一致性、隔离性、持久性。

redo log即重做日志，用于保证事务的持久性。

redo日志由两部分组成：1. rodo log buffer（内存中） 2. redo log file（磁盘）

InnoDB通过强制提交日志来保证事务的持久性，即当事务提交时必须先将所有的日志写入到重做日志文件进行持久化。

同时，当数据库崩溃时，也需要先读取日志进行redo，在对崩溃时尚未提交的事务进行undo

那么，既然都是对修改做的保存，那么redo log 和bin log有什么区别呢？

首先，redo log和bin log不处于一个层面，redo log是引擎层面的、bin log是mysql层面的。

其次，redo log 保存的是物理的修改，即文件，而bin log保存的是逻辑的修改，即sql语句等。

undo log即回滚日志，当我们的事务执行失败时，可用于将失败的语句进行回滚。所以可以保证事务的原子性。

与redo log不同，undo log存在于表空间中，且是逻辑日志。

在我们每次进行insert操作时，undo log中都会存储一条相对应的delete语句，执行该语句即可做到回滚。

同样，对于update和delete操作也都是如此。

而当我们事务提交后，undo log也不会立刻被删除，而是交给后台的线程进行删除。

为啥不删除呢？这也是undo log的另一项用途，多版本并发控制（MVCC）。

MVCC是一种用于实现事务隔离性的无锁机制。

我们之前了解过InnoDB的MVCC简单实现机制，这里再回顾一下：

在表中的每一条记录都维护着两个字段：该记录的创建ID和该记录的删除ID，这两个ID都于创建/删除该记录的事务ID决定。
当一个事务读取时，必须保证该记录的创建ID小于事务ID（保证该已经被创建），其删除ID大于该事务ID（保证该记录未被删除）
这样就保证了事务的隔离性。

然而，MYSQL中的MVCC并不是这样实现的。

Mysql中的MVCC由undo回滚日志、快照读和记录版本链来实现。

同样的，对于每一条回滚记录，都会维护两个字段，首先，还是该记录的事务ID，而另外一个字段是指向下一条记录。

具体来说，每一次对数据的更改，都会创建一条新的记录，然后将指针字段指向覆盖的那条记录。

这样，我们就维护了一个记录的版本链。

而当我们的事务第一次查询的时候，会生成一个一致性的视图，该视图维护了现在已经提交的事务ID和未提交的事务ID。

（视图主要包括2个部分，未提交的事务数组和已提交的事务ID最大值。）

我们查询的时候就会不断的对比记录的事务ID，判断该事务是否已经提交。然后就能读取到最近一次提交的记录。

（若事务ID小于视图中的最小事务ID，则表示已提交，若大于最大事务ID，则未提交，若ID在数组中，则未提交，不在则已提交）

注意，在可重复读隔离级别，我们在一个事务中的每一次查询都会沿用第一次的视图，这样就能保证两次同样的查询是一致的。

而在读已提交级别，我们每一次查询都会生成新的视图。