簡單分析MySQL 一則慢日誌監控誤報問題
導讀 | 這篇文章主要介紹了MySQL 一則慢日誌監控誤報的問題分析與解決,幫助大家更好的理解和使用MySQL,感興趣的朋友可以瞭解下 |
之前因為各種原因,有些報警沒有引起重視,最近放假馬上排除了一些潛在的人為原因,發現資料庫的慢日誌報警有些奇怪,主要表現是慢日誌報警不屬實,收到報警的即時通訊提醒後,隔一會去資料庫裡面去排查,發現慢日誌的效能似乎沒有那麼差(我設定的一個閾值是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 一則慢日誌監控誤報的問題分析與解決的詳細內容。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2757091/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 對 MySQL 慢查詢日誌的簡單分析MySql
- mysql慢查詢和錯誤日誌分析MySql
- Mysql事件監控日誌MySql事件
- mongodb profiling慢請求監控日誌MongoDB
- Mysql 慢日誌分析工具MysqldumpslowMySql
- 黑盒監控、日誌監控
- 關於MySQL 通用查詢日誌和慢查詢日誌分析MySql
- MySQL:慢查詢日誌MySql
- mysql開啟慢日誌MySql
- MySQL慢日誌優化MySql優化
- mysql 鎖的慢日誌MySql
- MySQL慢日誌全解析MySql
- 故障分析 | 從一則錯誤日誌到 MySQL 認證機制與 bug 的深入分析MySql
- 分散式系統監控(五)- 日誌分析分散式
- pgbadger 慢日誌分析工具
- 如何優雅地上報前端監控日誌前端
- mysql日誌系統簡單使用MySql
- mysql5.7 慢日誌配置MySql
- MySQL慢日誌功能分析及優化增強MySql優化
- 監聽MySQL的binlog日誌工具分析:CanalMySql
- Linux下使用GoAccess監控Nginx訪問日誌LinuxGoNginx
- 跟我一起學docker(15)--監控日誌和日誌管理Docker
- Kubernetes Ingress 日誌分析與監控的最佳實踐
- 小程式日誌監控工具
- 03-Loki 日誌監控Loki
- 慢查詢日誌開啟分析
- 線上公開課 | 監控與日誌的黃金法則
- net 日誌分析錯誤
- 【k8s】etcd叢集took too long to execute慢日誌告警問題分析K8S
- 使用kibana視覺化報表實時監控你的應用程式,從日誌中找出問題,解決問題視覺化
- mysql之 slow log 慢查詢日誌MySql
- MySQL Slow Query log(慢查詢日誌)MySql
- ELK監控nginx日誌總結Nginx
- Grafana、Prometheus、mtail-日誌監控GrafanaPrometheusAI
- 部署Sentry日誌監控系統
- MySQL 狂寫錯誤日誌MySql
- Mysql慢查詢日誌檔案轉ExcelMySqlExcel
- MySQL慢查詢日誌相關設定MySql