郑州 互联网 公司网站海外aso优化

在之前，我们已经讲了MySQL事务日志：redo log 和 undo log（是InnoDB engine存储引擎生成的）

当我们作为一个mysql client 来发起一个连接请求：经过了如下图示过程：

这章我们要讲的MySQL日志是在MySQL server上的
不管更改哪个存储引擎，今天所讲的这些日志都是有的。

MySQL支持 plugin engine 插件式的存储引擎，可以更换
这个MySQL日志主要分为4类：
错误日志
查询日志
二进制日志
慢查询日志
慢查询日志在我的另外一篇博客已经详细讲述。

MySQL日志

log_bin是二进制日志，只要是修改操作，在二进制日志都会出现。

打开my.ini,在后面加上上面的参数，保存后重启mysql服务就行了。


在开启log-bin=mysql-bin的时候还要同时加上 server-id=1(表示当前MySQL的身份）

设置过期的时间，否则总有一天磁盘被这个日志占满，导致服务器不可运行，设置7天后失效，超过7天后日志文件被删除掉

如果想要设置是持久的起作用：需要在配置文件上定义它，然后重启MySQL服务，就可以持久性的生效，而不会出现在每个session中都要自定义设置，然后session结束都恢复到原始状态的情况。

如果不自定义指定路径：默认在数据的路径：

在linux root下重启mysqld服务的命令：service mysqld restart

错误日志

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

查询日志

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

二进制日志

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

两个重要的应用场景：主从复制、数据恢复
主库所有的更新操作（update,delete,insert）都记录在binlog中，从库读主库的binlog，把binlog的所有操作像拍电影一样在从库上演一下。
查看binlog：mysql> show binary logs;
通过mysqlbinlog工具（mysql原生自带的工具）可以快速解析大量的binlog日志文件，如：

binlog演示

我们先刷新一下日志。
生成一个新的binlog

然后我们进行一些操作：


我们发现日志的filesize和刚才的不一样了。肯定记录刚才我们的操作。
如果我们直接cat日志的话，会发现不是明文，无法直接查看。

我们要通过
mysqlbinlog

我们进行操作：

@代表的是字段。详细地记录了对数据库的更改。


at 数字，指的是位置，区间，相当于当前事件在binlog发生的记录的位置，在进行恢复的方式进行数据恢复。

binlog数据恢复演示

我们现在创建一个数据库mytest，并且添加表和数据

假如现在有人把库删除了：

相当于这个库的所有表的所有数据都没有了！！！

这些操作都会记录在二进制日志binlog里面。
从理论上来说，可以从binlog把丢失的数据恢复出来。因为本身在恢复过程中产生的日志也要记录在binlog中，因为它毕竟是修改的操作。

在实际过程中，我们需要在很多的binlog找，库是在什么时候建的。

在配置binlog的时候，我们还配置了：
日志的过期时间：7天。（过期的数据进行备份，放在云数据库，云服务器中，或者在Linux shell，通过管道
同步把这个SQL脚本的数据在MySQL播放一下）

7天之前的数据怎么恢复？
MySQL数据的恢复靠的是SQL的数据备份（定期备份，每天或者每几天备份1次）加上binlog的数据恢复。
binlog只恢复上一次数据备份以后新增加的数据产生问题丢失，可以通过binlog恢复

之前的数据通过数据备份恢复（在SQL的文件脚本中），在~/data.sql里面，在MySQL上用source执行，就可以把之前备份的数据恢复到mysql这个库表中。备份之后新增加的数据通过binlog恢复就可以了。

我们回到实践上：我们刚才所做的操作都在000003上面
我们在数据恢复之前，首先执行flush logs；很明白的知道数据恢复最多恢复到这个binlog文件就可以了，从这个文件开始记录的是开始恢复后的那些操作。

我们再执行show

也就是说，我很明白的知道数据恢复最多恢复到这个000003文件就可以了。

我们把775记住。

然后我们看到，在1410被删库了。
我们执行：从000003恢复，通过管道放到MySQL shell上执行


mytest出来了！！！

数据从binlog恢复出来了

可以通过位置，也可以通过时间。

stop datatime
stop position

相当于是卡1个范围，从指定的binlog里面进行恢复，如果有多个binlog，就要从多个binlog里进行恢复。

慢查询日志

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和索引该怎么去优化。
show profiles命令可有查看sql具体的运行时间，全局变量的名字是：profiling