浅议我国旅游景点网站的建设,网站免费下载安装大全手机版,影视广告制作公司,爱用建站下载之前因为各种原因#xff0c;有些报警没有引起重视#xff0c;最近放假马上排除了一些潜在的人为原因#xff0c;发现数据库的慢日志报警有些奇怪#xff0c;主要表现是慢日志报警不属实#xff0c;收到报警的即时通信提醒后#xff0c;隔一会去数据库里面去排查#xf…之前因为各种原因有些报警没有引起重视最近放假马上排除了一些潜在的人为原因发现数据库的慢日志报警有些奇怪主要表现是慢日志报警不属实收到报警的即时通信提醒后隔一会去数据库里面去排查发现慢日志的性能似乎没有那么差(我设置的一个阈值是60)。排查过几次代码层面的逻辑没有发现明显的问题几次下来问题依旧这可激发了修正的念头决定认真看看到底是什么原因。后端使用的是基于ORM的模式数据都存储在模型MySQL_slowlog_sql_history对应的表中。代码层面是类似如下的逻辑MySQL_slowlog_sql_history.objects.filter(create_time__gt2020-01-29 11:00:00,Query_time_pct_95__gt60)传入的时间是动态的然后阈值取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(u2020-01-29 11:00:00, u600)看SQL没问题啊。我自己在客户端执行确实是好好的只过滤出了600秒以上的结果。select ip_addr,db_port from mysql_slowlog_sql_history where create_time2020-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));初始化几条数据。mysql insert into test_dummy(Query_time_pct_95 ) values(8.83736),(7.70056),(5.09871),(4.32582);Query OK, 4 rows affected (0.00 sec)Records: 4 Duplicates: 0 Warnings: 0mysql select * from test_dummy;-----------------------| 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_95600;Empty set (0.00 sec)mysql select *from test_dummy where Query_time_pct_95600;| 1 | 8.837364 || 2 | 7.700558 |2 rows in set (0.00 sec)可以看到使用了整型数值的时候没有返回结果而使用了字符类型的时候匹配的结果是按照最左匹配的模式来进行过滤的也就意味着在数据库层面对于浮点数的处理还是差别很大的。所以这个问题的快速修复方式就是在数据库层面修改数据表的类型为float,而在精度损失方面这块的影响是可以忽略不计的。再次验证这个问题就没有再次出现。
