之前因?yàn)楦鞣N原因，有些報(bào)警沒(méi)有引起重視，最近放假馬上排除了一些潛在的人為原因，發(fā)現(xiàn)數(shù)據(jù)庫(kù)的慢日志報(bào)警有些奇怪，主要表現(xiàn)是慢日志報(bào)警不屬實(shí)，收到報(bào)警的即時(shí)通信提醒后，隔一會(huì)去數(shù)據(jù)庫(kù)里面去排查，發(fā)現(xiàn)慢日志的性能似乎沒(méi)有那么差（我設(shè)置的一個(gè)閾值是60）。

排查過(guò)幾次代碼層面的邏輯，沒(méi)有發(fā)現(xiàn)明顯的問(wèn)題，幾次下來(lái)，問(wèn)題依舊，這可激發(fā)了修正的念頭，決定認(rèn)真看看到底是什么原因。

后端使用的是基于ORM的模式，數(shù)據(jù)都存儲(chǔ)在模型MySQL_slowlog_sql_history對(duì)應(yīng)的表中。

代碼層面是類似如下的邏輯：

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

傳入的時(shí)間是動(dòng)態(tài)的，然后閾值取60秒，按照預(yù)期如果報(bào)警出來(lái)就肯定是有問(wèn)題的。

為了進(jìn)一步驗(yàn)證，我把閾值時(shí)間修改為600，竟然還是報(bào)出錯(cuò)誤，執(zhí)行7~8秒的慢查詢照樣會(huì)報(bào)出來(lái)。

我使用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沒(méi)問(wèn)題啊。

我自己在客戶端執(zhí)行，確實(shí)是好好的，只過(guò)濾出了600秒以上的結(jié)果。

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;

對(duì)著這個(gè)結(jié)果我開(kāi)始反思，到底是什么原因呢？

我看著模型的字段定義開(kāi)始有所悟，然后快速驗(yàn)證了一番。

為了方便說(shuō)明，我創(chuàng)建了一個(gè)測(cè)試表test_dummy.

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

初始化幾條數(shù)據(jù)。

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)

然后使用如下的兩條語(yǔ)句來(lái)進(jìn)行對(duì)比測(cè)試。

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)

可以看到，使用了整型數(shù)值的時(shí)候，沒(méi)有返回結(jié)果，而使用了字符類型的時(shí)候，匹配的結(jié)果是按照最左匹配的模式來(lái)進(jìn)行過(guò)濾的，也就意味著在數(shù)據(jù)庫(kù)層面對(duì)于浮點(diǎn)數(shù)的處理還是差別很大的。

所以這個(gè)問(wèn)題的快速修復(fù)方式就是在數(shù)據(jù)庫(kù)層面修改數(shù)據(jù)表的類型為float,而在精度損失方面這塊的影響是可以忽略不計(jì)的。

再次驗(yàn)證，這個(gè)問(wèn)題就沒(méi)有再次出現(xiàn)。

以上就是MySQL 一則慢日志監(jiān)控誤報(bào)的問(wèn)題分析與解決的詳細(xì)內(nèi)容，更多關(guān)于MySQL慢日志監(jiān)控誤報(bào)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！