时间:2021-05-02
之前因为各种原因,有些报警没有引起重视,最近放假马上排除了一些潜在的人为原因,发现数据库的慢日志报警有些奇怪,主要表现是慢日志报警不属实,收到报警的即时通信提醒后,隔一会去数据库里面去排查,发现慢日志的性能似乎没有那么差(我设置的一个阈值是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:
? 1 2 3 4 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秒以上的结果。
? 1 2 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.
? 1 create table test_dummy(id int primary key auto_increment,Query_time_pct_95 varchar(100));初始化几条数据。
? 1 2 3 4 5 6 7 8 9 10 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)然后使用如下的两条语句来进行对比测试。
? 1 2 mysql> select *from test_dummy where Query_time_pct_95>600; Empty set (0.00 sec) ? 1 2 3 4 5 6 7 8 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慢日志监控误报的资料请关注服务器之家其它相关文章!
原文链接:https://cloud.tencent.com/developer/article/1586775
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
在开发项目中,我们可以通过MySQL的慢查询日志对有效率问题的SQL进行监控。下面一些命令是开启日志:查找慢查询日志文件的目录showvariableslike
PostgreSQL错误日志与慢查询日志对于线上系统分析、问题预警、问题排查起到非常重要的作用,在此不做赘述。此文档记录错误日志与慢查询日志的收集、分析与存储展
根据mysql慢日志监控SQL语句执行效率启用MySQL的log-slow-queries(慢查询记录)。在Linux环境下先要找到my.cnf文件(一般在/e
什么是慢查询慢查询的作用:通过慢查询分析,找到有问题的命令进行优化。和mysql的慢SQL日志分析一样,redis也有类似的功能,来帮助定位一些慢查询操作。Re
用MYSQL5.7.9作为ZABBIX2.4.7的监控数据库.前段时间开启了慢查询日志,后来发现慢查询日志膨胀到了700M查看最后100条大部分都是0.1秒的后