摘要

日志 的存在，为数据库的很多性能提供了 保障。像用于回滚数据的 undo log，用于复原数据的 redo log，以及用于主从备份的 binlog。本文将会大抵介绍下数据库里的日志类别，以及重点剖析下事务日志的相干知识点。

日志分类

在 mysql 里的日志品种有很多，从总体上来讲能够分为 Server 层 和 存储引擎层 的（对于 mysql 的总体架构能够看这篇：mysql 系列：总体架构概述）。

在 Server 层里的日志分类如下：

谬误日志

谬误日志是 mysql 在启动、运行或进行时出现异常的日志。咱们能够通过上面这个命令来查看谬误日志的地位：

SHOW VARIABLES LIKE 'log_error';

下面默认查问到的是 stderr，示意 规范谬误输入，如果有终端存在，则只会在终端打印谬误。当然，咱们也能够在 my.cnf 里设置谬误日志地位：

[mysqld]
 log-error= 谬误日志地位

应用场景：像咱们在启动 mysql 失败时，个别能够到谬误日志里查看。

通用查问日志

通用查问日志记录了用户的所有操作，包含 sql 语句的查问更新。个别状况下是不会开启的，有点相似于咱们平时应用 debug 级别的日志。同样的，咱们也能够通过上面的语句来查看是否开启及其输入地位：

SHOW VARIABLES LIKE '%general%';

当咱们想要开启通用查问日志，以记录所有客户端的 sql 操作时，就能够用上面的语句了：

SET GLOBAL general_log=on;

下面的日志输入是到文件，如果想要应用 sql 语句来查找日志，能够将日志的输入设置为表：

SET GLOBAL log_output='table';

而后就能够应用上面的 sql 语句来查问了：

select * from mysql.general_log;

这样就能够监控到 所有客户端 的操作状况了，当然，不要遗记应用完后敞开日志，否则将会占用很大的磁盘空间。

DDL 日志

DDL 日志记录了数据库里 元数据 的变更信息。DDL 即 数据定义 语句，像 create，drop，alter语句。

DDL 日志是一个二进制文件，不被人为的浏览批改，也没有其余配置项能够配置它。个别寄存在数据目录下，ddl_log.log 文件即是。而且在胜利启动 mysqld 后会被删除，只有在记录元数据时才会被从新创立。

binlog 二进制日志

binlog 日志记录了数据库 对数据的批改 记录，包含了 DDL，如表的创立，数据更新等。但并不包含 select 这些查问语句.

binlog 日志是属于逻辑语句的记录，可用于主从数据库的同步。

relay log 中继日志

relay log 用于主从备份复原应用的。当 master 将 binlog 传送过去后，slave 服务器会有一个 I/O 线程来解决接管到的日志，并且将其保护到 relay log 里。

relay log 有了主服务器的 binlog 逻辑操作语句后，就能够 还原 数据库了。

relay log 除了蕴含 binlog 的内容，还会记录以后复原到哪个地位。如果从服务器断开重连，则能够从上次记录的地位开始复原。

慢查问日志

慢查问日志用于记录在 mysql 里执行工夫超过预期值的耗时语句，次要用于性能瓶颈剖析。

个别慢查问记录须要手动设置：

SET GLOBAL slow_query_log=1;

至于其日志的记录地位，能够这么查问：

SHOW VARIABLES LIKE '%slow_query_log%';

而工夫阈值的查问则如下：

SHOW VARIABLES LIKE 'long_query_time%';

对应的设置语句：

SET GLOBAL long_query_time=8;

事务日志

事务日志是 InnoDB 存储引擎为了反对事务的 长久化 而设计的，次要是 redo log 和 undo log。

redo log

redo log 是对加载到内存 数据页 的批改后果 的记录，和 binlog 不同的是，binlog 记录的是逻辑操作语句，偏差于过程记录。而 redo log 是一个数据页的批改日志，偏差于后果的记录。

在 mysql 里每当执行一个事务时，并不会时时的将数据批改同步到硬盘上。而是会在内存里保护了一个 buffer pool，在读取更新数据的时候会优先从这里操作，数据不存在则会从磁盘加载后再操作。

而内存里批改的数据也不会始终驻留着，会定时的更新到磁盘上，这就是所谓的 脏页刷盘。

仔细的敌人可能会发现内存数据并不牢靠，要是产生断电，导致 buffer pool 里的数据不能落地到磁盘，那岂不是会失落数据？这个就是 redo log 发挥作用的时候了。

每当有事务执行操作后，会将刚刚对数据页的批改后果先记录到 redo log，而后才提交事务。这种日志后行的做法，保障了即便来不及同步数据也能从日志里复原。

事实上，在批改了内存数据页并写入 redo log 后，事务此时也只是标记为 prepare 状态而已，并不会标为 commit 状态，只有当 binlog 也写入胜利后才会真正的 commit。

之所以要把 binlog 写入胜利后才算残缺 commit，次要是因为 binlog 用于从数据库的复原，如果 redo log 写入胜利，binlog 没有写入胜利，那么就会导致主数据库有此操作后果的数据，而从数据库同步时缺失数据。

这种 2 次提交状态，被 mysql 称为了二阶段提交。除此之外，redo log、binlog 还有个组提交的过程，次要是用于批量的进行事务的提交，日志的写入。

undo log

回滚日志次要用于回滚数据，和 redo log 不一样的是，undo log 是逻辑日志，是一种相同操作的记录，比方在回滚时，如果是 insert 操作时，则会逆向为 delete，delete 操作时，逆向为 insert 操作，更新则复原到过后的版本数据。

undo 还用于 MVCC 版本链的应用，具体能够看看这篇文章：MVCC。

总结

在 mysql 一开始其实没有事务日志，起初有了 InnoDB 存储引擎，须要反对事务长久化的个性，所以有了 redo log，undo log。尽管对于开发而言，可能不会波及到对 mysql 日志相干的运维，但它的实现原理还是值得学习的，或者当前也能实现属于本人的一个长久化数据库~~~ ㋡㋡㋡

感兴趣的敌人能够搜一搜公众号「阅新技术」，关注更多的推送文章。
能够的话，就顺便点个赞、留个言、分享下，感激各位反对！
阅新技术，浏览更多的新常识。