之前因為各種原因，有些報警沒有引起重視，最近放假馬上排除了一些潛在的人為原因，發(fā)現(xiàn)數(shù)據(jù)庫的慢日志報警有些奇怪，主要表現(xiàn)是慢日志報警不屬實，收到報警的即時通信提醒后，隔一會去數(shù)據(jù)庫里面去排查，發(fā)現(xiàn)慢日志的性能似乎沒有那么差（我設置的一個閾值是60）。
排查過幾次代碼層面的邏輯，沒有發(fā)現(xiàn)明顯的問題，幾次下來，問題依舊，這可激發(fā)了修正的念頭，決定認真看看到底是什么原因。
后端使用的是基于ORM的模式，數(shù)據(jù)都存儲在模型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)
傳入的時間是動態(tài)的，然后閾值取60秒，按照預期如果報警出來就肯定是有問題的。
為了進一步驗證，我把閾值時間修改為600，竟然還是報出錯誤，執(zhí)行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沒問題啊。
我自己在客戶端執(zhí)行，確實是好好的，只過濾出了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; |
對著這個結果我開始反思，到底是什么原因呢？
我看著模型的字段定義開始有所悟，然后快速驗證了一番。
為了方便說明，我創(chuàng)建了一個測試表test_dummy.
|
1
|
create table test_dummy(id int primary key auto_increment,Query_time_pct_95 varchar(100)); |
初始化幾條數(shù)據(jù)。
|
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) |
可以看到，使用了整型數(shù)值的時候，沒有返回結果，而使用了字符類型的時候，匹配的結果是按照最左匹配的模式來進行過濾的，也就意味著在數(shù)據(jù)庫層面對于浮點數(shù)的處理還是差別很大的。
所以這個問題的快速修復方式就是在數(shù)據(jù)庫層面修改數(shù)據(jù)表的類型為float,而在精度損失方面這塊的影響是可以忽略不計的。
再次驗證，這個問題就沒有再次出現(xiàn)。
以上就是MySQL 一則慢日志監(jiān)控誤報的問題分析與解決的詳細內(nèi)容，更多關于MySQL慢日志監(jiān)控誤報的資料請關注服務器之家其它相關文章！
原文鏈接：https://cloud.tencent.com/developer/article/1586775
