当前位置:网站首页>MySQL:日志系统介绍 | 错误日志 | 查询日志 | 二进制日志:bin-log数据恢复实践 | 慢日志查询

MySQL:日志系统介绍 | 错误日志 | 查询日志 | 二进制日志:bin-log数据恢复实践 | 慢日志查询

2022-08-10 01:56:00 _索伦

前言

对于之前文章里提到的redo log和undo log是存储引擎的日志,而本章介绍的是MySQL Server的日志。

在这里插入图片描述

错误日志

错误日志是 MySQL 中最重要的日志之一,它记录了当 mysqld 启动和停止时,以及服务器在运行过程中发生任何严重错误时的相关信息。当数据库出现任何故障导致无法正常使用时,可以首先查看此日志。
mysqld 使用错误日志名 host_name.err(host_name 为主机名) 并默认在参数 DATADIR(数据目录)指定的目录中写入日志文件。

cordump error exception…

查询日志

查询日志记录了客户端的所有语句。由于上线项目sql特别多,开启查询日志IO太多导致MySQL效率
低,只有在调试时才开启,比如通过查看sql发现热点数据进行缓存。

mysql> show global variables like “%genera%”;

二进制日志

二进制日志(BINLOG)记录了所有的 DDL(数据定义语言)语句和 DML(数据操纵语言) 语句,但是不包括数据查询语句。语句以“事件”的形式保存,它描述了数据的更改过程。 此日志对于灾难时的数据恢复起着极其重要的作用。

两个重要的应用场景:主从复制、数据恢复

查看binlog:mysql> show binary logs;
通过mysqlbinlog工具(mysql原生自带的工具)可以快速解析大量的binlog日志文件,如:

shell> mysqlbinlog --no-defaults --database=school --base64-output=decode-rows
-v --start-datetime=‘2022-08-01 00:00:00’ --stop-datetime=‘2022-08-10 00:00:00’
mysql-bin.000001 | more

bin-log数据恢复实践示例

首先创建一个表,增加一些数据,

在这里插入图片描述

假设不消息删掉了库:

在这里插入图片描述

查看日志,大概知道刚才的操作存放在哪部分日志里:
在这里插入图片描述

进入路径

/var/lib/mysql

在这里插入图片描述
找到刚才的log并查看:

mysqlbinlog binlog.000040

在这里插入图片描述

在这里可以看到之前做过的SQL

在这里插入图片描述

在这里插入图片描述

恢复操作:利用想要恢复的起始位置和截至位置 + 文件名

在这里插入图片描述

查看是否成功:
已成功恢复

在这里插入图片描述

慢查询日志

MySQL可以设置慢查询日志,当SQL执行的时间超过我们设定的时间,那么这些SQL就会被记录在慢查询日志当中,然后我们通过查看日志,用explain分析这些SQL的执行计划,来判定为什么效率低下,是没有使用到索引?还是索引本身创建的有问题?或者是索引使用到了,但是由于表的数据量太大,花费的时间就是很长,那么此时我们可以把表分成n个小表,比如订单表按年份分成多个小表等。

慢查询日志相关的参数如下所示:

在这里插入图片描述

慢查询日志记录了包含所有执行时间超过参数 long_query_time(单位:秒)所设置值的 SQL语句的日志,在MySQL上用命令可以查看,如下:

在这里插入图片描述

这个值是可以修改的,如下:
在这里插入图片描述

现在修改成超过1秒的SQL都会被记录在慢查询日志当中!可以设置为0.01秒,表示10毫秒。

慢查询日志,默认名称是host_name-slow.log,存放在MySQL的数据路径下,内容格式显示大致如
下:

在这里插入图片描述
通过查询慢查询日志,发现项目运行过程中,上面这条SQL语句的执行时间超过了设定的慢查询时间,那么接下来就需要用explain分析一下该SQL的执行计划了,根据具体情况找出SQL和索引该怎么去优化。

原网站

版权声明
本文为[_索伦]所创,转载请带上原文链接,感谢
https://sauron7i.blog.csdn.net/article/details/126250772