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慢日志监控误报的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • 关于Anemometer图形化显示MySQL慢日志的工具搭建及使用的详细介绍

    介绍:Anemometer 是一个图形化显示MySQL慢日志的工具.结合pt-query-digest,Anemometer可以很轻松的帮你去分析慢查询日志,让你很容易就能找到哪些SQL需要优化 This is the Box Anemometer, the MySQL Slow Query Monitor. This tool is used to analyze slow query logs collected from MySQL instances to identify proble

  • MySQL慢日志实践小结

    慢日志查询作用 慢日志查询的主要功能就是,记录sql语句中超过设定的时间阈值的查询语句.例如,一条查询sql语句,我们设置的阈值为1s,当这条查询语句的执行时间超过了1s,则将被写入到慢查询配置的日志中. 慢查询主要是为了我们做sql语句的优化功能. 慢查询配置项说明 登录mysql服务,使用如下命令 mysql> show variables like '%query%'; +------------------------------+----------------------------

  • mysql 5.5 开启慢日志slow log的方法(log_slow_queries)

    mysql 5.5 开启慢日志slow log的方法(log_slow_queries)

    1.MySQL 5.5命令行里面 复制代码 代码如下: set global log_slow_queries = on;                               # 开启慢日志 set [session|global]  long_query_time =0.2               # 设置时间.精确的毫秒 set global  log_queries_not_using_indexes = on;   # 设置无索引的查询 2.查看存放日志的形式 mysql>

  • MySQL中按时间获取慢日志信息的方法

    今天处理一个case: 数据库异常,连接数突增. 想着分析一下慢日志,可是一看慢日志都好几G了,而且是短日志格式,找到那个时间点相对比较难.于是写了一个脚本从慢日志按时间提取点日志.脚本: https://github.com/wubx/mysql-binlog-statistic/blob/master/bin/cutlogbytime 使用方法: 复制代码 代码如下: cutlogbytime #用于从慢日志用截取一个时间段的日志方便分析 ./cutlogbytime /path/slowl

  • MySQL的慢日志线上问题及优化方案

    MySQL 慢日志(slow log)是 MySQL DBA 及其他开发.运维人员需经常关注的一类信息.使用慢日志可找出执行时间较长或未走索引等 SQL 语句,为进行系统调优提供依据. 本文将结合一个线上案例,分析如何正确设置 MySQL 慢日志参数和使用慢日志功能,并介绍下网易云 RDS 对 MySQL 慢日志功能的增强. MySQL 参数组功能 网易云 RDS 实例提供了参数组管理功能,可通过参数管理界面查看绝大部分常用的 MySQL 系统参数,用户可了解当前运行值和建议值: 用户还可通过参

  • 根据mysql慢日志监控SQL语句执行效率

    根据mysql慢日志监控SQL语句执行效率 启用MySQL的log-slow-queries(慢查询记录). 在Linux环境下先要找到my.cnf文件(一般在/etc/mysql/),然后可能会发现该文件修改后无法保存,原因是你没有相应的权限,可以从属性中看到该文件的所有者是root,这时要先以root的身份打开它: sudo nautilus /etc/mysql 接着再打开my.cnf文件然后找到[mysqld]标签在下面加上: log-slow-queries=/path/slow.lo

  • 详解mysql慢日志查询

    慢日志查询作用 慢日志查询的主要功能就是,记录sql语句中超过设定的时间阈值的查询语句.例如,一条查询sql语句,我们设置的阈值为1s,当这条查询语句的执行时间超过了1s,则将被写入到慢查询配置的日志中. 慢查询主要是为了我们做sql语句的优化功能. 慢日志查询配置项说明 打开mysql,通过以下命令查看相关配置: mysql> show variables like '%query%'; +------------------------------+---------------------

  • MySQL 一则慢日志监控误报的问题分析与解决

    之前因为各种原因,有些报警没有引起重视,最近放假马上排除了一些潜在的人为原因,发现数据库的慢日志报警有些奇怪,主要表现是慢日志报警不属实,收到报警的即时通信提醒后,隔一会去数据库里面去排查,发现慢日志的性能似乎没有那么差(我设置的一个阈值是60). 排查过几次代码层面的逻辑,没有发现明显的问题,几次下来,问题依旧,这可激发了修正的念头,决定认真看看到底是什么原因. 后端使用的是基于ORM的模式,数据都存储在模型MySQL_slowlog_sql_history对应的表中. 代码层面是类似如下的逻

  • MySQL删除表时I/O错误的原因分析与解决

    MySQL删除表时I/O错误的原因分析与解决

    问题现象 最近使用sysbench测试MySQL,由于测试时间较长,写了一个脚本按prepare->run->cleanup的顺序在后台跑着.跑完后察看日志发现一个问题,MySQL服务的错误日志中出现多条类似以下信息的报错: [ERROR] InnoDB: Trying to do I/O to a tablespace which does not exist. I/O type: read, page: [page id: space=32, page number=57890], I/O

  • Flex读取txt文件中的内容报错原因分析及解决

    Flex读取txt文件中的内容报错原因分析及解决

    Flex读取txt文件中的内容 1.具体错误如下  2.错误原因 读取文件不存在 复制代码 代码如下: var file:File = new File(File.applicationDirectory.nativePath+"/phone.txt"); 3.解决办法 将文件导入进去

  • python监控日志中的报错并进行邮件报警

    目录 前言 实现思路 实现代码 前言 在测试过程中,注意力往往都在功能上,如果功能正常,是基本不会查看日志的,反之会查看日志定位问题.但是表面上的功能正常不能确保日志没有报错,不能确保其他功能点没有问题,这时我们就需要日志的监控,一旦有报错就触发报警机制(报警机制可以有邮件报警.钉钉微信发消息报警等),我选择的是发邮件报警. 实现思路 1.在测试过程中,日志时时在刷,时时监控难度太大 2.转换思路,每分钟对日志进行扫描一次,发现报错即报警 a.获取当前时间前一分钟的日志,并将日志全部写入一个文件

  • Mysql启动报ERROR：2002的分析与解决

    前言 本文主要给大家介绍了关于Mysql启动报ERROR:2002的分析与解决,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧. 1.故障现象 [root@localhost scripts]# mysql -u root ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysqld.sock' (2) 2.故障分析 查看mysql实例的状态 [root@localhost

  • Mysql挂掉后无法重启报pid文件丢失的解决方法

    阿里云单核2G的配置挂着两个企业网站,访问量一般.最近每天几乎都会出现网站打不开显示数据库链接失败的问题. 多方寻求原因发现,mysql的pid文件缺失,并无法重启自建,后来也看了其他帖子说关闭日志什么的未果,查看系统日志发现,是因为内存满了导致mysql进程被杀,然后就一直挂起状态. Sep 25 11:33:48 iZ28jcqqr7lZ kernel: Out of memory: Kill process 23201 (mysqld) score 53 or sacrifice chil

  • MySQL读取Binlog日志常见的3种错误

    1. mysqlbinlog: [ERROR] unknown variable 'default-character-set=utf8mb4' 当我们在my.cnf中添加default-character-set=utf8mb4选项,那么在mysqlbinlog查看binlog时就会报错. 解决方案:.mysqlbinlog 后面添加 --no-defaults 选项 例如: mysql bin可执行文件所在路径/bin/mysqlbinlog --no-defaults binlog所在目录

  • Mysql实现企业级日志管理、备份与恢复的实战教程

    背景 随着业务的发展,公司业务和规模不断扩大,网站积累了大量的用户信息和数据,对于一家互联网公司来说,用户和业务数据是根基.一旦公司的数据错乱或者丢失,对于互联网公司而言就等于说是灭顶之灾,为防止系统出现操作失误或系统故障导致数据丢失,公司要求加强用户数据的可靠性,要求全面加强数据层面备份,并能在故障发生时第一时间恢复. 数据备份形式 文件备份: 通过Linux的备份命令把文件统一打个包存起来,可存在本地和远程服务器,等到要恢复时,再用这些文件恢复到指定位置. 数据库数据备份: 在一些对数据可靠

  • 浅析springcloud 整合 zipkin-server 内存日志监控

    Zipkin Zipkin是一款开源的分布式实时数据追踪系统(Distributed Tracking System),基于 Google Dapper的论文设计而来,由 Twitter 公司开发贡献.其主要功能是聚集来自各个异构系统的实时监控数据. Zipkin主要包括四个模块  - Collector           接收或收集各应用传输的数据  - Storage            存储接受或收集过来的数据,当前支持Memory,MySQL,Cassandra,ElasticSea

随机推荐