简单分析MySQL 一则慢日志监控误报问题

这篇文章主要介绍了MySQL 一则慢日志监控误报的问题分析与解决，帮助大家更好的理解和使用MySQL，感兴趣的朋友可以了解下

之前因为各种原因，有些报警没有引起重视，最近放假马上排除了一些潜在的人为原因，发现数据库的慢日志报警有些奇怪，主要表现是慢日志报警不属实，收到报警的即时通信提醒后，隔一会去数据库里面去排查，发现慢日志的性能似乎没有那么差（我设置的一个阈值是60）。

排查过几次代码层面的逻辑，没有发现明显的问题，几次下来，问题依旧，这可激发了修正的念头，决定认真看看到底是什么原因。后端使用的是基于ORM的模式，数据都存储在模型MySQL_slowlog_sql_history对应的表中。

代码层面是类似如下的逻辑：

MySQL_slowlog_sql_history.objects.filter(create_time__gt='2020-01-29 11:00:00',Query_time_pct_95__gt=60)

传入的时间是动态的，然后阈值取60秒，按照预期如果报警出来就肯定是有问题的。为了进一步验证，我把阈值时间修改为600，竟然还是报出错误，执行7~8秒的慢查询照样会报出来。我使用debug的方式得到了ORM解析得到的SQL:

SELECT...`mysql_slowlog_sql_history`.`create_time`, `mysql_slowlog_sql_history`.`memo`
FROM `mysql_slowlog_sql_history`
WHERE (`mysql_slowlog_sql_history`.`create_time` > '2020-01-29 11:00:00' AND `mysql_slowlog_sql_history`.`Query_time_pct_95` > '600') LIMIT 21;
args=(u'2020-01-29 11:00:00', u'600')

看SQL没问题啊。我自己在客户端执行，确实是好好的，只过滤出了600秒以上的结果。

select ip_addr,db_port from mysql_slowlog_sql_history
where create_time>'2020-01-29 00:00:00' and Query_time_pct_95 > 600;

对着这个结果我开始反思，到底是什么原因呢？我看着模型的字段定义开始有所悟，然后快速验证了一番。为了方便说明，我创建了一个测试表test_dummy.

create table test_dummy(id int primary key auto_increment,Query_time_pct_95 varchar(100));

初始化几条数据。

insert into test_dummy(Query_time_pct_95 ) values('8.83736'),('7.70056'),('5.09871'),('4.32582');
+----+-------------------+
| id | Query_time_pct_95 |
+----+-------------------+
| 1 | 8.83736      |
| 4 | 7.70056      |
| 7 | 5.09871      |
| 10 | 4.32582      |
+----+-------------------+
4 rows in set (0.00 sec)

然后使用如下的两条语句来进行对比测试。

mysql> select *from test_dummy where Query_time_pct_95>600;
Empty set (0.00 sec)

mysql> select *from test_dummy where Query_time_pct_95>'600';
+----+-------------------+
| id | Query_time_pct_95 |
+----+-------------------+
| 1 | 8.837364     |
| 2 | 7.700558     |
+----+-------------------+
2 rows in set (0.00 sec)

可以看到，使用了整型数值的时候，没有返回结果，而使用了字符类型的时候，匹配的结果是按照最左匹配的模式来进行过滤的，也就意味着在数据库层面对于浮点数的处理还是差别很大的。所以这个问题的快速修复方式就是在数据库层面修改数据表的类型为float,而在精度损失方面这块的影响是可以忽略不计的。再次验证，这个问题就没有再次出现。

以上就是MySQL 一则慢日志监控误报的问题分析与解决的详细内容。

简单分析MySQL 一则慢日志监控误报问题相关推荐

mysql 慢日志报警_一则MySQL慢日志监控误报的问题分析
之前因为各种原因,有些报警没有引起重视,最近放假马上排除了一些潜在的人为原因,发现数据库的慢日志报警有些奇怪,主要表现是慢日志报警不属实,收到报警的即时通信提醒后,隔一会去数据库里面去排查,发现慢日志 ...
anemometer mysql 500_Anemometer MySQL 慢查询日志监控平台
Anemometer 是一款开源的(慢查询)日志监控平台,当前主要用于 MySQL 的慢查询日志跟踪. Anemometer 演示地址:http://lab.fordba.com/anemometer ...
使用ELK分析Mysql慢查询日志
目录 1.ELK介绍 2.ELK安装及问题解决 3.架构 4.Mysql慢查询配置 5.具体分析 6.参考资料 1.ELK介绍 1)Elasticsearch Elasticsearch 是基于 JS ...
linux日记的监控与分析,linux下apache日志监控与分析——webalizer与awstat
(一) Webalizer 从webalizer官网(http://www.webalizer.org/)我们可以看到对其做的如下说明,从中我们可以对webalizer有一个简单的了解 The W ...
使用mysqldumpslow和mysqlsla分析mysql慢查询日志
MySQL优化不是一劳永逸的工作,而是一个持久战.其中慢查询日志的分析是一个重要手段,以前我总是手动大概看看,不过这实在不是长久之计,今天试用了一下mysqldumpslow和mysqlsla,感觉效 ...
shell脚本分析mysql慢查询日志（slow log）
使用percona公司的pt-query-digest分析慢查询日志.分析.统计的结果的比較清晰 #!/bin/sh slowlog_path=/root/slow_query_log everysl ...
php mysql primary key_简单分析MySQL中的primary key功能_MySQL
在5.1.46中优化器在对primary key的选择上做了一点改动: Performance: While looking for the shortest index for a covering ...
大数据实时案例--实时日志监控告警系统
本次介绍使用Flume+kafka+storm+mysql的实时日志监控告警系统,代码部分比较多,会放在一个下载的连接里面,可以免费下载. 需求在软件开发中国,上线运行时经常会出现一些报错,但是我们 ...
mysql把data移走后报错_【mysql案例】Failedtoopenlog--datadir物理迁移报错
1.1.1.mysql5.6.14的datadir迁移时遇到报错 [环境描述] 在机器A上安装了perconamysql 5.6.14,数据库停启正常,datadir路径为pathA,并且已经做了应用 ...

简单分析MySQL 一则慢日志监控误报问题

简单分析MySQL 一则慢日志监控误报问题相关推荐

最新文章

热门文章