前言

最近在看《高性能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官网文档地址，心愿大家多多反对和关注。