MySql监控（普通日志、慢查询日志、Dashboard、Performance Reports等）

MySql版本：Server version: 8.0.19 MySQL Community Server

图形化界面工具：MySql Workbeach 8.0 CE

测试在Docker环境下进行，如何使用Docker安装Mysql，请参考我的另外一篇博客：https://blog.csdn.net/dap769815768/article/details/99588480

一、普通日志记录。

1）如果想监控所有的sql请求，可以使用开启mysql的普通日志的方式，开启方法参考下面的sql语句：

-- 查看变量
show variables like '%general_log%';
-- 设置日志存储路径
set global general_log_file='/var/lib/mysql/log/general.log';
-- 开启普通日志记录
set global general_log=on;
-- 查看日志记录方式
show variables like '%log_output%';
-- 设置日志记录方式为表
set global log_output='table';
-- 从数据表里面查看日志
select * from mysql.general_log order by event_time desc;

上述列的命令包含两种日志记录的方式，一种是将日志记录到文件，一种是记录到表。记录到文件的话，可以使用tail命令来查看实时的日志：

tail -f -n 20 /home/mysql/log/general.log

表示查看最新的20条数据。

2）设置日志路径可能会存在权限问题，尤其是在Docker环境下，解决办法是进入到Docker内部：

docker exec -it mysql /bin/bash

设置log目录的权限：

chmod 777 /var/lib/mysql/log

这里我把log目录的权限对文件所属组，文件所有者，其他用户都开启了读写执行三个权限。

3）日志会记录所有的数据库的所有的sql请求，不管是成功的还是失败的。所以会占用数据库不少资源，同时，时间久了，日志文件会很大。所以一般这个普通日志只有在排查问题的时候才会开启，平时是不开启的。执行命令：

set global general_log=off;

这样日志就被实时关闭了。

二、慢查询日志

1）大部分时间，开启的都是慢查询。所谓慢查询就是数据库耗时较长的语句（语句不仅仅包含查询语句，还有插入语句，更新语句等），多长时间算长，mysql默认是超过10s的算长，不过这个是可以设置的。慢查询相关的设置方法如下：

-- 查看慢查询的默认阈值
show variables like '%long_query_time%';
-- 设置慢查询的阈值为1ms
set long_query_time=0.001;
-- 查询慢查询是否开启和日志保存路径
-- 其中slow_launch_time是线程创建的阈值
-- 当线程创建时间超过这个值后，slow_launch_time的值+1
show variables like '%slow%';
-- 设置慢查询日志保存路径
set global slow_query_log_file='/var/lib/mysql/log/slow.log';
-- 开启慢查询日志
set global slow_query_log=on;
-- 设置慢查询日志的保存方式为数据表
set global log_output='table';
-- 从数据表里面查看慢查询日志
select * from mysql.slow_log;
-- 慢查询把不使用索引的查询也记录下来，
-- 这会导致日志量很大，同时也会导致慢查询日志中会存在query_time小于阈值的记录
show variables like '%not_using_indexes%';
-- 关闭记录不使用索引的查询
set global log_queries_not_using_indexes=off;
-- 如果要打开不使用索引的查询，为了减少日志量，
-- 也可以限制下每分钟这类日志的量
set global log_throttle_queries_not_using_indexes=10;
-- 删除日志不可以使用delete，会报错，使用truncate
truncate TABLE mysql.slow_log;

注：上面的修改不会影响已经打开的会话，因为一个连接会话打开后，会读取相关的配置并不会定时刷新配置，因此如果已经打开的会话，希望配置修改生效，需要关掉会话重新打开。比如如果你修改了慢查询的阈值，你会发现你已经打开的会话并不会受到影响，因为这个阈值在当前会话打开的时候已经读取了，后续的修改，并不会更新已经读取到的值。

2）慢查询时间久了，也会导致日志量很大，解决办法是定期清理，或者把日志分割，如果是文件记录的方式，可以写一个脚本，定期另存一下慢查询的日志文件，把原来的日志清空掉。如果是表记录的方式，可以定期将数据转移到另外一个张表里面，清空掉正在用的表的数据。具体怎么做，这里就不提供方法了。

3）慢查询的两个参数：lock_time、query_time。分别指锁等待的时间，和实际的执行时间（包含锁等待的时间）。只有当一个SQL的执行时间（不包括锁等待的时间 lock_time）>long_query_time的时候，才会判定为慢查询SQL。当一个SQL的执行时间（不包括lock_time）小于long_query_time的时候（即使他锁等待超过了很久），也不会记录到慢查询日志当中的。所以总结下来，慢查询是指sql本身执行的很久的查询，和锁等这些因素没有关系。关于这一点可以采用开启一个串行化事务隔离级别的方式进行验证：

-- 查看当前会话的事务隔离级别
show variables like '%isolation%';
-- 设置事务隔离级别为串行化
set session transaction isolation level serializable;
-- 开启事务
begin;
-- 执行更新语句
update new_schema.new_table set content='aaa' where id=1;
-- 提交事务
commit;

如果你对数据库的事务隔离级别不是很了解，可以参考我的另外一篇博客：https://blog.csdn.net/dap769815768/article/details/101101425。

这篇文章虽然是基于Postgresql写的，但是数据库的隔离级别是相通的，都是基于SQL标准的，并没有多大差别，你完全可以把Postgresql的事务隔离级别放到Mysql来用。

三、Workbench的Performance Reports的使用。

如果没有开启日志，那么也可以通过Workbench自带的一些监控工具，了解数据库的性能状况。比如Performance Reports。这里面的统计信息很多，如图：

这里面有一个很有用的统计，就是High Cost Sql Statements，打开后，找到Statement Analysis，这里面统计的是耗时较长的sql语句，详细记录了这些sql语句执行的次数，最高耗时，平均耗时等等信息，如下图：

Performance Reports还有很多非常有用的统计，比如Full Table Scans，比如Memory Usage等等，值得花时间去研究一下。

四、Workbench的Dashboard使用

Mysql Workbench是官方的Mysql图形化工具，里面自带的许多小工具，都是很有用的，比如它的Dashborad面板。这个Dashboard面板和很多第三方的Dashboard面板功能都差不多，里面记录着当前执行的sql数量并进行分类，连接总数等等。

这些东西应该能够基本满足一个正常场景的需求了，另外Workbench还可以增加插件，开启更多的功能。