在MySQL 中日志監控出現報錯如何解決

在MySQL 中日志監控出現報錯如何解決？針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

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

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 中日志監控出現報錯如何解決問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。