前言

最近在看《高性能 Mysql》- 宁海元版一书的时候，原本想找对于 mysql 所有日志的介绍，深刻理解这些日志在整个 mysql 中表演的角色和作用，然而没有发现这块的汇总，零散的在书中散布，而后翻看了 mysql 官网文档中，也是在各种不同的中央简略介绍了日志，为了不便加深本人对 mysql 日志的了解，决定汇总一下这些 mysql 下的不同日志，所以写下这篇文章。

一、Mysql 日志是什么？

所谓日志，就是一种将行为动作记录到一个中央，这个中央能够是文件，文本等可存储的载体。
Mysql 日志就是记录整个 mysql 从启动，运行，到完结的整个生命周期下的行为。

二、Mysql 日志类别

1.General Query Log 一般查问日志

• Log Control at Server Startup
• Log Control at Runtime

General Query Log 是在服务器启动时和运行时的记录。

# 查看一般查问日志是否开启

show VARIABLES like "%general_log"

# 开启形式

set global general_log = ON

设置日志保留的地位

set global general_log_file='D:\\log\\general.lg'

执行一条 SQL 查问语句：

select id from test;

关上 general.log 发现这条语句被残缺记录下来了。

留神：当开启 general_Log 后，mysql 中的所有操作将会记录下来，这样 general_Log 文件就会产生很大的文件，此时须要清空此文件来开释磁盘空间，因而个别默认都是不开启 general_Log。

2.Slow Query Log 慢查问日志

查问日志由执行工夫超过 long_query_time 几秒且至多 min_examined_row_limit 须要查看行的 SQL 组成
** 留神：
mysqld 在执行完所有锁之后，会在慢查问日志中写入一条语句，因而日志程序可能与执行程序不同 **

查看慢查问日志是否开启

show variables like 'slow_query%'

默认查问超过几秒才记录(个别状况下，默认是 10 秒)

show variables like 'long_query_time';

设置慢查问日志保留文件

set global slow_query_log_file='D:\\log\\slow.log'

测试执行一条慢查问语句

select sleep(11);

这里能够看出是那个 sql 以及查问工夫。

慢查问日志内容解读：

• Query_time: duration
语句执行工夫，以秒为单位。
• Lock_time: duration
获取锁的工夫（以秒为单位）。
• Rows_sent: N
发送到客户端的行数。
• Rows_examined:
服务器层查看的行数（不包含存储引擎外部的任何解决）。
• Set timestamp：
语句蕴含批示慢语句何时被记录的工夫戳（在语句实现执行后产生）

开启慢查问日志中蕴含慢治理语句(ALTER TABLE、ANALYZE TABLE、CHECK TABLE、CREATE INDEX、DROP INDEX、OPTIMIZE TABLE 和 REPAIR TABLE)

show VARIABLES like '%log_slow_admin_statements%'
set global log_slow_admin_statements = on

写入慢查问日志的语句中蕴含不应用索引进行行查找的查问

show VARIABLES like '%log_queries_not_using_indexes%'
set global log_queries_not_using_indexes = on

测试一下应用索引和不应用索引谁会生成慢查问日志？

select age from test;  //age 查问不应用索引
select id from test;  //id 查问应用索引

2.Binary Log 二进制日志

The binary log contains“events”that describe database changes such as table creation operations or changes to table data. It also contains events for statements that potentially could have made changes (for example, a DELETE which matched no rows), unless row-based logging is used. The binary log also contains information about how long each statement took that updated data

二进制日志蕴含形容数据库更改的“事件”，例如表创立操作或表数据更改, 还蕴含可能已进行更改的语句的事件（例如，DELETE 不匹配任何行），还蕴含无关每条语句应用更新数据多长时间的信息。

二进制日志的益处

1. 复制操作 (可了解为 同步)，复制源服务器上的二进制日志提供了要发送到正本的数据更改的记录。源将其二进制日志中蕴含的事件发送到其正本，正本执行这些事件以进行与源上雷同的数据更改。
2. 数据恢复操作 ( 灾备 应用)，复原备份后，将从新执行备份后记录的二进制日志中的事件，这些事件使数据库从备份点开始更新。

查看 MySQL 的二进制日志是否开启

show variables like ‘%log_bin%’;

关上文件 my.ini，在该文件的 [mysqld] 语句下，增加以下 log-bin = mysql-bin。

重启 mysql 服务，开启二进制日志。

Binary Log 操作测试

插入数据

insert into test values(21,21);

删除数据

delete from test where id =10

查看 binlog 日志事件

show binlog events in 'mysql-bin.000001';

查看具体详细信息，可到 mysql 装置目录下应用

mysqlbinlog -vv Data/mysql-bin.000001 --start-position=219

解释一下这几个事件类型：
Format_desc：
它是 binlog 文件中的第一个事件，而且，该事件只会在 binlog 中呈现一次，常指定了 MySQL Server 的版本，binlog 的版本，该 binlog 文件的创立工夫。
Previous_gtids：
记录该 binlog 文件之前执行过的所有事务对应的 GTID 汇合，在系统启动时，mysql 读取该事件的内容来进行相应的初始化工作。
Gtid：
全局事务 ID 是一个对于已提交事务的全局惟一的编号，随着事务记录到 binlog 中，用来标识事务，每一个事务都会有一个，GTID 实际上是由 server_uuid + transaction_id 组成。
server_uuid：
一个 mysql 实例的惟一标识，每一台 mysql 实例的 server_uuid 都是不同的。在 mysql 第一次启动时，会主动生成并长久化到 auto.cnf 文件（寄存在 mysql 的数据目录下）。
transaction_id：
该实例上曾经提交的事务数量，transaction_id 是一个从 1 开始的自增计数，示意在这台 mysql 实例上执行的第 n 个事务，随着事务的减少，此 id 顺次递增。

Query：

• 事务开始时，在 binlog 中记录一个类型为 query_event 的 begin 事件。

  • statement 格局 binlog 中，具体执行的 SQL 语句保留在 query_event 事件中。
  • row 格局 binlog，所有 DDL 操作以文本的格局记录在 query_event 事件中。

Xid：
statement 和 row 格局的 binlog，都会增加一个 XID_EVENT 事件作为事物的完结。
该事件记录了该事务的 id，解体复原时，依据事务在 binlog 中的提交状况决定是否提交存储引擎中 prepared 的事务，一个事务产生的所有 event 会被 GTID_LOG_EVENT 和 XID_EVENT 包住。
Table_map：负责映射须要的表。
Write_rows：负责写入数据。
Delete_rows：负责删除数据。

3.Relay Log 中继日志

从服务器 I / O 线程将主服务器的二进制日志读取过去记录到从服务器本地文件，而后从服务器 SQL 线程会读取 relay-log 日志的内容并利用到从服务器，从而使从服务器和主服务器的数据保持一致。

查看中继日志

show variables like '%relay%';

max_relay_log_size
relay log 容许的最大值，如果该值为 0，则默认值为 max_binlog_size (1G)；
如果不为 0，则 max_relay_log_size 则为最大的 relay_log 文件大小；
relay_log
relay_log 的地位和名称，如果值为空，则默认地位在数据文件的目录；
relay_log_index
relay_log 索引的地位和名称，记录有几个 relay_log 文件，默认为 2 个
relay_log_info_file
relay-log.info 的地位和名称
relay-log.info 记录 master 主库的 binary_log 的复原地位和 从库 relay_log 的地位；
relay_log_purge
是否主动清地面继日志，默认值为 1(启用)；
relay_log_recovery
当 slave 从库宕机后，如果 relay-log 损坏了，导致一部分中继日志没有解决，则主动放弃所有未执行的 relay-log，并且从新从 master 上获取日志，这样就保障了 relay-log 的完整性。默认状况下该性能是敞开的，将 relay_log_recovery 的值设置为 1 时，可在 slave 从库上开启该性能，倡议开启；
sync_relay_log
设置为 1 时，slave 的 I / O 线程每次接管到 master 发送过去的 binlog 日志都要写入零碎缓冲区，而后刷入 relay log 中继日志里，这样是最平安的，因为在解体的时候，你最多会失落一个事务，但会造成磁盘的大量 I /O；
设置为 0 时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，尽管安全性升高了，但缩小了大量的磁盘 I / O 操作。这个值默认是 0，可动静批改；
sync_relay_log_info
这个参数和 sync_relay_log 参数一样。

4.Audit Log 审核日志

目前只有 MySQL 企业版本能力应用这个，MySQL 社区版暂不反对

5.Error Log 谬误日志

谬误日志蕴含 mysqld 启动和敞开工夫的记录。它还蕴含诊断音讯，例如在服务器启动和敞开期间以及在服务器运行期间产生的谬误、正告和正文。

查看谬误日志

show variables like 'log_error';

6.DDL 元数据日志

DDL 元数据日志
DDL 日志或元数据日志记录了影响表分区的数据定义语句生成的元数据操作，MySQL 应用 DDL 日志来复原中断的元数据操作。DDL 日志寄存在数据目录中，文件名为 ddl_log.log，它是一个二进制日志，不要人为地编辑这个日志。

7.Redo Log 重做日志

未完待续。。。。。。

8.Undo Log 撤销日志

未完待续。。。。。。

总结

redo 重做日志和 undo 撤销日志打算专门出一篇文章来具体介绍，这两个的篇幅比拟长，敬请期待哈。
以上就是这次对 mysql 各种日志的一篇汇总，次要参照 mysql 官网文档资料并退出本人的实际和了解，贴一下 mysql 官网文档地址，心愿大家多多反对和关注。