校园春色亚洲色图_亚洲视频分类_中文字幕精品一区二区精品_麻豆一区区三区四区产品精品蜜桃

主頁 > 知識庫 > MySQL 一則慢日志監控誤報的問題分析與解決

MySQL 一則慢日志監控誤報的問題分析與解決

熱門標簽:地圖標注被騙三百怎么辦 云南語音外呼系統平臺 常州電銷外呼系統一般多少錢 天智外呼系統 北京人工外呼系統價錢 400電話鄭州申請 福州呼叫中心外呼系統哪家好 沃克斯電梯外呼線路圖 房產智能外呼系統品牌

之前因為各種原因,有些報警沒有引起重視,最近放假馬上排除了一些潛在的人為原因,發現數據庫的慢日志報警有些奇怪,主要表現是慢日志報警不屬實,收到報警的即時通信提醒后,隔一會去數據庫里面去排查,發現慢日志的性能似乎沒有那么差(我設置的一個閾值是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慢日志監控誤報的資料請關注腳本之家其它相關文章!

您可能感興趣的文章:
  • 詳解mysql慢日志查詢
  • 關于Anemometer圖形化顯示MySQL慢日志的工具搭建及使用的詳細介紹
  • MySQL慢日志實踐小結
  • MySQL的慢日志線上問題及優化方案
  • mysql 5.5 開啟慢日志slow log的方法(log_slow_queries)
  • MySQL中按時間獲取慢日志信息的方法
  • 根據mysql慢日志監控SQL語句執行效率
  • MySQL 慢日志相關知識總結

標簽:沈陽 移動 黔東 拉薩 珠海 徐州 沈陽 鹽城

巨人網絡通訊聲明:本文標題《MySQL 一則慢日志監控誤報的問題分析與解決》,本文關鍵詞  MySQL,一則,慢,日志,監控,;如發現本文內容存在版權問題,煩請提供相關信息告之我們,我們將及時溝通與處理。本站內容系統采集于網絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《MySQL 一則慢日志監控誤報的問題分析與解決》相關的同類信息!
  • 本頁收集關于MySQL 一則慢日志監控誤報的問題分析與解決的相關信息資訊供網民參考!
  • 推薦文章
    主站蜘蛛池模板: 南宫市| 盈江县| 云霄县| 万宁市| 江津市| 邵东县| 新蔡县| 乐安县| 阿勒泰市| 土默特右旗| 镇宁| 海门市| 金寨县| 大洼县| 昌乐县| 德化县| 辉县市| 平陆县| 宝坻区| 东方市| 青冈县| 桑日县| 诸城市| 资溪县| 安乡县| 曲周县| 永嘉县| 德格县| 海门市| 平远县| 长顺县| 吐鲁番市| 美姑县| 高阳县| 鞍山市| 太原市| 澜沧| 恭城| 玉环县| 子洲县| 南阳市|