一、日志的分类

二、错误日志

首次启动会提示错误日志位置
查询错误日志存放路径

[root@db01 ~]# mysqladmin -uroot -pEgon@123 variables | grep -w log_error 

或者
[root@db01t ~]# mysql -uroot -pEgon@123 mysql> show variables like '%log_error%';

配置错误日志（默认就是启用的）
[root@localhost ~]# vim /etc/my.cnf
#绝对路径
log_error=/var/log/mysql.errlog
#相对路径
#log_error=mysql.errlog
[root@localhost ~]# touch /var/log/mysql.errlog
[root@localhost ~]# chmod 640 /var/log/mysql.errlog
[root@localhost ~]# chown mysql.mysql /var/log/mysql.errlog [root@localhost ~]# systemctl restart mysqld 1234567891011

MySQL中，其中log_error定义是否启用错误日志的功能和错误日志的存储位置，此外还可以用参数控制是否将告警信息（warning messages）也写入错误日志。在不同的版本中改控制参数有所不同
在MySQL 5.6中用log_warnings参数
log_warnings=0， 表示不记录告警信息。
log_warnings=1(默认值)， 表示告警信息写入错误日志。 log_warnings大于1，表示各类告警信息，例如有关网络故障的信息和重新连接信息写入错误日志。

mysql5.7新增的log_error_verbosity参数
#它有三个可选值， 分别对应：
#log_error_verbosity=1：错误信息；
#log_error_verbosity=2：错误信息和告警信息；(推荐) #log_error_verbosity=3（默认值就是3）：错误信息、告警信息和通知信息。

三、事务日志

1.redo log

redo，顾名思义“重做日志”，是事务日志的一种。每次操作都先记录到redo日志中，当出现实例故障（像断电），导致数据未能更新到数据文件，则数据库重启时须redo，重新把数据更新到数据文件

1）作用

在事务ACID过程中，实现的是“ D ”持久化的作用。
REDO：记录的是，内存数据页的变化过程
特性:WAL(Write Ahead Log)日志优先写

2.undo log

1）作用

undo，顾名思义“回滚日志”，是事务日志的一种。
在事务ACID过程中，实现的是“A”原子性的作用。当然CI的特性也和undo有关

3.事务日志工作流程

四、一般查询日志

1.默认是关闭的 一般不会开启，因为哪怕你开启事务一顿操作，最后不提交也会记录，生产上程序跑sql很多，会非常 非常占地方，从来都不启动，要看操作去binlog

2.开启
[root@db01 ~]# vim /etc/my.cnf general_log=on general_log_file=/var/log/select.log
#可以使用set global general_log=on;设置

[root@localhost ~]# touch /var/log/select.log
[root@localhost ~]# chmod 640 /var/log/select.log
[root@localhost ~]# chown mysql.mysql /var/log/select.log [root@localhost ~]# systemctl restart mysqld 3.查看一般查询日志 [root@db01 ~]# mysqladmin -uroot -pEgon@123 variables|grep general_log

或者
[root@db01 ~]# mysql -uroot -pEgon@123 mysql> show variables like ‘%gen%’;

五、慢查询日志

慢查询日志作用

1）将mysql服务器中影响数据库性能的相关SQL语句(不论是什么语句，增删改查)记录到日志文件
2）通过对这些特殊的SQL语句分析并改进，提高数据库性能

配置慢日志

#默认慢日志是不开启的
[root@db01 ~]# vim /etc/my.cnf
[mysqld]
#指定是否开启慢查询日志
slow_query_log = 1

#指定慢日志文件存放位置（默认在data）
slow_query_log_file=/var/log/slow.log

#设定慢查询的阀值(默认10s)
long_query_time=0.05

#不使用索引的慢查询日志是否记录到日志
log_queries_not_using_indexes=ON

#查询检查返回少于该参数指定行的SQL不被记录到慢查询日志，少于100行的sql语句查询慢的话不记 录，一般不使用
#min_examined_row_limit=100 #鸡肋

执行下述命令
touch /var/log/slow.log
chmod 640 /var/log/slow.log
chown mysql.mysql /var/log/slow.log
systemctl restart mysqld

测试慢日志

测试方式一
测试:BENCHMARK(count,expr)
SELECT BENCHMARK(50000000,2*3);
#执行卡死，查看执行的sql执行时间，如果停不下来 可以 kill id
show processlist;
kill 3;

测试方式二

insert city_new select * from city; 
insert city_new select * from city_new; 
insert city_new select * from city_new; 
insert city_new select * from city_new;

查看方式一
查看慢日志可以使用
cat /service/mysql/data/slow.log
看起来太费劲，我们使用方式二

查看方式二
mysqldumpslow -s r -t 10 /var/log/slow.log
得到按照时间排序的前10条里面含有左连接的查询语句
参数说明:
-s:指定排序方式
c、t、l、r分别是按照记录次数、时间、查询时间、
返回的记录数来排序，ac、at、al、ar，表示相应的倒叙
-t:是top n的意思，即为返回前面多少条的数据；
-g:后边可以写一个正则匹配模式，大小写不敏感的；

查看方式三
yum provides pt-query-digest

六、二进制日志

6.1 二进制日志简介

二进制日志即binlog日志，记录了mysql数据库所有的dml,ddl语句事件（不包含select）。记录增删改，也可以记录SQL语句及行记录变化，还可以记录这些操作事件；总之会记录所有修改操作的SQL语句。
不要混淆以下三种日志：
（1）general log：记录数据库里的所有SQL操作记录
（2）redo log：只记录innodb存储引擎的修改日志
（3）binlog：只记录server层面内部的修改情况。–select /show 不记录

6.2 开启binlog日志的好处

（1）数据恢复：可以基于时间点恢复，以及根据其进行增量与差异备份
（2）mysql主从复制，通过binlog实现数据复制

6.3 二进制日志的工作模式

（1）语句模式：binlog_format=statement（Mysql5.7.6之前的默认级别）

#语句模式介绍
记录对数据库做出修改的sql语句,不记录该sql的上下文信息
例如
1、开启binlog日志后，我们在某个库下自定义函数，若想定义成功需要先设置配置项
set global log_bin_trust_function_creators=TRUE;

2、然后自定义函数
delimiter //
create function f1(
i1 int,
i2 int)
returns int
BEGIN
declare num int;
set num = i1 + i2;
return(num);
END //
delimiter ;

3、最后执行一条插入语句
insert into t1(name) values(concat(“egon”,f1(1,2)));

如果使用statement模式，那么这条insert语句将会被记录到二进制日志中,而sql语句中依赖的f1 的定义是不会记录下来的，f1只存在于当前库。

#优点
不需要记录细到每一行数据的更改变化，因此，binlog日志量小，IO压力小，性能较高

例如:
一条语句修改了100万行，该模式下只需要记录下该条语句即可

#缺点
日志中记录的sql语句可能有上下文依赖，此时脱离了当前数据库环就无法运行了，因此该模式下容易 出现主从不一致的问题。

例如：
主库记录的某条sql语句引用了主库中的函数、触发器、存储过程等特殊功能
在从库上接收了该sql之后，可能就无法正确运行，从而主从库数据不一致的问题。
ps：row模式是基于每一行来记录变化的，所以不会出现类似的问题。

#应用场景
sql语句对mysql内置功能依赖比较少：不使用存储过程/触发器/函数，可以使用该模式，否则还是推 荐行级模式

（2）行级模式：binlog_format=row，（mysql5.7.6之后+8.0的默认级别,优先使用）
#行级模式介绍
记录每一行数据修改的细节，即哪一条记录被修改了，修改成什么样了

例如：执行语句（f1参照上例，此处略）
insert into t1(name) values(concat(“egon”,f1(1,2)));

如果使用row模式，那么日志中会记录插入了一条新记录，记录中的name字段值为’egon3’

#优点
相当于把上下文依赖都记录了下来，可以更方便查看每一条数据修改的细节，并且不会出现某些特定 情况下的存储过程或function以及trigger的调用和触发无法被正确复制的问题，即该模式下主从复 制强一致，数据最安全。

#缺点
日志量大

例如
一条语句修改了100万行，语句模式下只需要记录一条语句即可
而行级模式却修改记录下100万行的修改记录，binlog日志的量可能会大得惊人。

#应用
sql语句对mysql内置功能依赖比较多，希望数据最安全，复制强一致的场景推荐行级模式

（3）混合模式：binlog_format=mixed，一般不用
#混合模式介绍
结合 row level 与statement level的优点
混合（mixed-based）模式默认采用语句模式记录日志，在一些特定的情况下会将记录模式切换为行 级模式记录，这些特殊情况包含但不限于以下情况。
•当函数中包含UUID()时。
•当表中有自增列（AUTO_INCREMENT）被更新时。
•当执行触发器（trigger）或者存储过程（stored function）等特殊功能时。
•当FOUND_ROWS()、ROW_COUNT()、USER()、CURRENT_USER()、CURRENT_USER等执行时。

#应用场景
看上去这种方式似乎比较美好，但是在生产环境中，为了保险起见，一般会使用row模式。

6.4 binlog日志相关概念

二进制日志文件，顾名思义，它是二进制的，所以我们不能直接使用cat命令进行查看，而是需要通过一些别的命令查看其内容，而且，二进制日志文件，有”事件”和”位置”的概念，什么是事件呢？

(1) 事件events
通俗的讲，我们可以把binlog中的每一条记录当做一个”事件”，因为binlog记录了所有对数据库进行的修改，所以，我们可以认为，数据库的修改被记录到二进制日志中，这些记录每一条都可以理解为一个”事 件”。

(2) 位置position
由于二进制日志文件是二进制的，所以，我们可以把整个二进制文件想象成一个字节序列。假设，二进制日志文件刚开始是空的，从第1个字节开始记录，假设记录第一个”事件”（第一条记录），需要15个字节，那么第一个事件的开始”位置”就是1，结束”位置”就是15，由于前15个字节已经被第一个事件占用，那么当我们想要通过二进制日志记录第二个事件时，则需要从第15个字节向后开始记录，假设记录第二个”事件”需要20个字节，那么第二个事件在binlog中的起始”位置”就是15，结束”位置”就是35，以此类推。

6.5 二进制日志相关参数

(1) server_id
服务ID,主从库必须不一样，建议数字为:ip+端口，5.7.3以后版本,必须指定

(2) log-bin
此变量用于控制是否开启二进制日志，而且这是一个只读变量，默认值为OFF

当我们启动数据库以后，在当前数据库连接中查看此变量的值，此变量值可能为OFF，表示不记录二进 制日志，如果想要记录二进制日志，只需将此值设置为二进制日志的文件名即可，但是需要注意的是， 我们无法在当前会话中使用set命令设置log_bin的值，因为它是一个只读变量，我们只能通过修改 my.cnf的方式，设置log_bin的值，假设，我们编辑my.cnf文件，设置log_bin的值为mybinlog， 那么，在mysql的数据目录中，将会自动生成一个以mybinlog为文件名前缀的二进制日志文件，如果 想要再次禁用binlog，只需要将log_bin这一行配置从my.cnf文件中注释即可，或者将其删除，重启 mysql服务后，再次查看log_bin的值，其值为OFF，注意，不要直接在my.cnf文件中将log_bin的值 设置为ON或者OFF，如果这样做，你将会看到以ON或者OFF为文件名前缀的二进制日志文件。换句话 说，如果my.cnf配置文件中没有log_bin的配置，则表示未开启二进制日志，如果my.cnf中存在 log_bin的配置，那么则表示开启了二进制日志，同时二进制日志文件的名称将会以log_bin对应的值 为文件名前缀，同时，二进制日志文件的后缀名会进行自动编号，每次日志滚动后，后缀名编号自动加 1。

示例：
log-bin=/var/lib/mysql/mybinlog #绝对路径
#log-bin=mybinlog #也可以用相对路径， 会在$datadir下产生mysqlbinlog-00000N

(3) log_bin_index
不设置的话，会根据log_bin值名称自动生成mybinlog.index log_bin_index=var/lib/mysql/mybinlog.index

(4) sql_log_bin
默认为ON
此变量用于标识当前会话中的操作是否会被记录于二进制日志，此变量值设置为ON，则表示在当前数据 库连接中，对数据库进行修改的语句将会被记录到binlog中，此变量值设置为OFF，则表示在当前数据 库连接中，对数据库进行的修改的语句将不会被记录到binlog中，在主从复制结构中，这些语句由于没 有被binlog记录，所以也不会同步到从节点中。换句话说，即使在my.cnf配置文件中设置了log_bin 的值，当前会话中，如果sql_log_bin的值设置为OFF，当前会话的操作也不会记录在二进制日志中。 而且需要注意的是，sql_log_bin是一个会话界别的变量，只能在当前会话中使用set sql_log_bin 命令进行设置，不能使用set global sql_log_bin命令进行设置，因为它是会话级别的变量，而 且，sql_log_bin也不能配置在my.cnf文件中，否则可能会无法启动mysql。

(5) binlog_format
此变量值得含义上文已经解释过，此变量的值决定了二进制日志的记录方式，此变量的值可以设置为 statement、row、mixed，分别表示以语句的形式记录二进制日志，以数据修改的形式记录二进制日 志，以混合的方式记录二进制日志，安全保险起见，推荐使用row的方式记录。

(6) max_binlog_size
设置单个二进制日志文件的最大大小，以字节为单位，超过此值大小，则二进制日志文件会自动滚动， 比如设置为500M为524288000。

(7) sync_binlog
在存储引擎章节中我们提过：
innodb_flush_log_at_trx_commit控制redo日志的刷盘策略，建议值为1 sync_binlog控制binlog日志的刷盘策略，建议值为1

当我们把innodb_flush_log_at_trx_commit设置为1的时候，表示事务提交时，事务日志立马从内 存刷写到磁盘中的事务日志文件中，而sync_binlog对于二进制日志的作用，就像 innodb_flush_log_at_trx_commit对于事务日志的作用，由于二进制日志一开始存在于内存 （binlog_cache）中，如果将sync_binlog设置为1，则表示每1次事务提交之后，都会立即将内存 中的二进制日志立即同步到磁盘中的二进制日志文件中，如果将sync_binlog设置为0，则表示当事务 提交之后，mysql不会立即将内存中的binlog刷写到磁盘中的binlog日志文件中，而是由文件系统决 定什么时候刷写，这可能取决于文件系统的缓存机制，当此值设置为0时，一旦操作系统宕机，那么将 丢失未从内存中同步到磁盘中的binlog，所以，当此值设置为0时，安全性最差，但是性能最高，当此 值设置为1时，安全性最高，性能最差，除了将此值设置为0或1，还能设置为N，假设将此值设置为3， 则表示每3次事务提交后，将binlog从内存刷写到磁盘一次，值设置的越大，有可能丢失的日志数据将 会越多，当然，性能会越好，在追求安全的情况下，推荐设置为1，但是听说，此值设置为0和设置为1 时在性能上的差距还是比较明显的，如果设置为0或N，最好为操作系统准备带有备用电源的缓存。

(8) 其他参数
#打开才能查看详细记录，默认为off
binlog_rows_query_log_events=on
#表示自动删除10天以前的日志
expire_logs_days=10
#full,minimal,noblob分别表示binlog中内容全记录，只记录被操作的，和不记录二进制
binlog_row_image=full #（full,minimal,noblob）

6.5 查看binlog配置项

show variables like ‘%log_bin%’;
show variables like ‘%binlog%’;
show variables like ‘%binlog_format%’;
show variables like ‘%server%’;
show variables like ‘expire_logs_days’; – 过期日志天数

#或者
[root@db01 ~]# mysqladmin -uroot -pEgon@123 variables |grep -w log_bin

6.6 开启binlog

1.默认是关闭的
2.配置开启binlog
vim /etc/my.cnf
[mysqld] server_id=1
log-bin=/var/lib/mysql/mybinlog
binlog_format=‘row’ #(row,statement,mixed)，不建议随意去修改binlog工作模式 binlog_rows_query_log_events=on
max_binlog_size=100M

6.7 查看binlog日志

查看日志日志名、状态、事件
show binary logs;
show master logs;
show master status;
show binlog events in ‘mybinlog.000002’;
show binlog events in ‘mybinlog.000002’ limit 3;

查看日志内容
#1、执行下述sql
create database if not exists test;
use test;
create table user(name varchar(10));
begin;
insert into user values(“egon1”),(“egon2”),(“egon3”);
update user set name=“EGON” where name=“egon1”;
commit;
show master status; – binlog的当前position

#查看binlog，看看有没有记录，二进制文件我们看不了，有专门的命令

查看全部：
#mysqlbinlog mybinlog.000002

按时间：
#mysqlbinlog mybinlog.000002 --start-datetime=“2022-11-05 10:02:56”
#mysqlbinlog mybinlog.000002 --stop-datetime=“2022-11-05 11:02:54”
#mysqlbinlog mybinlog.000002 --start-datetime=“2022-11-05 10:02:56” --stop- datetime=“2022-11-05 11:02:54”

按字节数：
#mysqlbinlog mybinlog.000002 --start-position=337
#mysqlbinlog mybinlog.000002 --stop-position=662
#mysqlbinlog mybinlog.000002 --start-position=337 --stop-position=662

如果是行级模式，想要看懂详细内容则需要加上额外参数，但是仅用于看懂内容，如果要用于还原数 据，还是应该去掉额外的参数并将内容定位到文件中 #mysqlbinlog --base64-output=decode-rows -vvv mybinlog.000002 # 仅用于查看，不能用于日后的数据恢复

#mysqlbinlog mybinlog.000002 --start-position=100 > /tmp/1.sql # /tmp/1.sql 可用于日后的数据恢复

6.8 binlolg可以用来恢复数据

#修改数据
begin; update user set name=“XXX” where name=“egon2”;
commit;

#发现自己修改错了
select * from user; #回滚，回滚不了，已经提交了

rollback;
select * from user;
#一怒之下删表
drop table user;

#恢复数据:查看binlog数据的起始点与要恢复到的位置点，导出成SQL mysqlbinlog mybinlog.000002 --stop-position=772 > /tmp/binlog.sql
mysql -uroot -pEgon@123 < /tmp/binlog.sql

6.9 刷新与清除二进制日志

(1) 刷新binlog
#刷新binlog：关闭当前的二进制日志文件并创建一个新文件
1）手动执行命令刷新
flush logs;
或者
mysqladmin -uroot -p flush-logs;
或者
mysql -uroot -pEgon@123 -e ‘flush logs’
2）重启数据库时会刷新
3）二进制日志上限（max_binlog_size）;当binlog达到1G,自动刷新

(2) 清除binlog
#清除二进制日志原则
在存储能力范围内，能多保留则多保留
基于上一次全备前的可以选择删除

1. 删除所有binlog，相当于重置
   reset master;

2. 删除指定binlog名之前的所有binlog(保留指定的binlog)
   purge binary logs to ‘mybinlog.00003’; – mybinlog.00003之前的都删除掉

3）删除日期之前的日志：手动执行
PURGE MASTER | BINARY LOGS BEFORE ‘date’ --用于删除日期之前的日志，BEFORE变量的 date自变量可以为’YYYY-MM-DD hh:mm:ss’格式

如：（MASTER 和BINARY 在这里都是等效的）
PURGE MASTER LOGS TO ‘mybinlog.00003’;
purge binary logs before ‘2021-07-13 19:11:00’;

还可以做减法：如只保留3天的
PURGE BINARY LOGS BEFORE now() - INTERVAL 3 day;

4）删除日期之前的日志：修改配置参数，让mysql自动执行
删除7天前的binlog
#临时生效
SET GLOBAL expire_logs_days = 7;

#永久生效
[root@db01 data]# vim /etc/my.cnf
[mysqld]
expire_logs_days = 7