Mysql日志知多少？

前言

最近在看《高性能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官方文档地址，希望大家多多支持和关注。