一則MySQL慢日誌監控誤報的問題分析

2020-12-21 楊建榮的資料庫筆記

之前因為各種原因,有些報警沒有引起重視,最近放假馬上排除了一些潛在的人為原因,發現資料庫的慢日誌報警有些奇怪,主要表現是慢日誌報警不屬實,收到報警的即時通信提醒後,隔一會去資料庫裡面去排查,發現慢日誌的性能似乎沒有那麼差(我設置的一個閾值是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));

初始化幾條數據。

mysql> insert into test_dummy(Query_time_pct_95 ) values('8.83736'),('7.70056'),('5.09871'),('4.32582');

Query OK, 4 rows affected (0.00 sec)

Records: 4 Duplicates: 0 Warnings: 0

mysql> select * from test_dummy;

+----+-------------------+

| 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';

| 1 | 8.837364 |

| 2 | 7.700558 |

2 rows in set (0.00 sec)

可以看到,使用了整型數值的時候,沒有返回結果,而使用了字符類型的時候,匹配的結果是按照最左匹配的模式來進行過濾的,也就意味著在資料庫層面對於浮點數的處理還是差別很大的。

所以這個問題的快速修複方式就是在資料庫層面修改數據表的類型為float,而在精度損失方面這塊的影響是可以忽略不計的。

再次驗證,這個問題就沒有再次出現。

相關焦點

  • MySQL優化:定位慢查詢的兩種方法以及使用explain分析SQL
    開啟慢查詢日誌(默認是關閉的):mysql> set global slow_query_log = on;Query OK, 0 rows affected (0.00 sec)設置慢查詢時間限制(查詢時間只要大於這個值都將記錄到慢查詢日誌中,單位:秒):mysql> set global long_query_time = 1;
  • Prometheus 監控MySQL資料庫
    Prometheus 監控mysql容器Prometheus這裡我們演示中,prometheus以及mysqld_exporter都使用容器進行運行。這裡我們就不以容器進行運行,使用二進位安裝的方式官方下載地址https://prometheus.io/download/#node_exporter#由於官方下載可能比較慢,我將壓縮包上傳到我的站點存儲,本次演示的版本為1.0.0
  • 資料庫基礎:mysql主從集群搭建
    對於一個mysql伺服器, 一般有兩個線程來負責複製和被複製。當開啟複製之後。1. 作為主伺服器Master, 會把自己的每一次改動都記錄到 二進位日誌 Binarylog 中。(從伺服器會負責來讀取這個log, 然後在自己那裡再執行一遍。)
  • MySQL 是怎麼死鎖的?
    來源於: https://blog.csdn.net/tr1912/article/details/81668423最近總結了一波死鎖問題,和大家分享一下。Mysql 鎖類型和加鎖分析MySQL有三種鎖的級別:頁級、表級、行級。
  • MySQL授權管理與結構分層
    在資料庫操作過程,經常會遇到分配普通用戶權限問題,root權限是最高權限,本文講述了權限管理語法和SQL_MODE語義和權限解析優化器(代價)執行器查詢緩存日誌記錄二進位日誌存儲引擎層從磁碟讀取數據頁返回給SQL層資料庫結構
  • MySQL中InnoDB-Cluster 日常運維掃盲-愛可生
    擅長 MySQL、PostgreSQL、MongoDB 等開源資料庫相關的備份恢復、SQL 調優、監控運維、高可用架構設計等。目前任職於愛可生,為各大運營商及銀行金融企業提供 MySQL 相關技術支持、MySQL 相關課程培訓等工作。 本文來源:原創投稿 *愛可生開源社區出品,原創內容未經授權不得隨意使用,轉載請聯繫小編並註明來源。
  • MySQL 工作、底層原理,看這一篇就夠了!
    它根據MySql AB公司提供的文件訪問層的一個抽象接口來定製一種文件訪問機制(這種訪問機制就叫存儲引擎)SQL 語句執行過程資料庫通常不會被直接使用,而是由其他程式語言通過SQL語句調用mysql,由mysql處理並返回執行結果。那麼Mysql接受到SQL語句後,又是如何處理?
  • 你有遇到過慢日誌大小飆升的經歷嗎-愛可生
    一般開啟慢日誌,我們只需要設置 slow_query_log=ON,slow_query_log_file= 存放路徑,long_query_time= 慢查詢的閾值即可,正常情況下慢日誌大小不會有大的起伏。但是,之前遇到過一次慢日誌增長很快的情況,當查看慢日誌具體內容時,並沒有發現有耗時很高的 sql,只看到大量執行時間小於 1 秒的 sql 被記錄進來。
  • 搞定MySQL安裝難安裝貴問題
    背景本方案解決了windows下安裝MySQL過程繁瑣的問題。是真正的免安裝綠色方法,不用配環境變量,不用執行install命令,不用配置my.ini文件。>命令成功生成data目錄,同時生成無密碼的root用戶啟動MySQLbin下執行mysqld--console設置root密碼執行mysql-uroot-p連入資料庫,密碼不用輸入,直接按回車進入mysql>
  • mysql性能分析explain之id詳解
    前言在mysql的編程世界裡,有時候我們往往需要對自己編寫的sql語句進行分析,來去查看sql的執行計劃,這個還是很有必要的。因為我們在開發中,往往需要從資料庫中查詢數據,當數據量一旦大的時候,這個時候就會出現查詢瓶頸,我們首先呢可能就會去查看我們的sql語句的執行過程,判斷是否可進行優化,那如何去定位分析呢?這個就是本文講到的使用explain工具來去定位分析。說明由於explain這個分析工具查詢出來的欄位過多,本文主要講第一部分,id的講解。
  • mPaaS框架下如何使用 CrashSDK 對閃退進行分析?
    目前 mPaaS Android 是使用的是 Crash SDK 對閃退進行的處理,Crash SDK 是 Android 平臺上一款功能強大的崩潰日誌收集 SDK,有著極高的崩潰收集率和完整、全面的崩潰日誌信息,生成的日誌內容非常利於問題的跟進和解決。
  • MySQL 8.0 中的索引可以隱藏了…
    例如:mysql> SELECT    INDEX_NAME,    IS_VISIBLE       FROM INFORMATION_SCHEMA.STATISTICS       WHERE TABLE_SCHEMA = 'db1' AND TABLE_NAME = 'javastack';
  • 一次日誌框架問題解決
    第一次啟動這個項目的時候、就報了如下的錯誤比較令人意外的是、只有我啟動時出現了這個錯誤。而其他開發同事並沒有出現這個問題。其實當時解決這個問題還是花費了不少的時間、第一個對這個項目不熟悉、第二個對公司自研的框架不熟悉、第三個當時沒有準確地認識到問題的根本(其實是對日誌框架的不熟悉)。其實第三個是最直接的原因。
  • PMP學習|如何利用《問題日誌》
    每一個問題都會有一個明確的負責人,每個問題都有承諾的解決日期,項目經理應該及時跟蹤,確保問題在既定的日期內得以解決。問題日誌對所有的相關方都是透明的,目的是為了邀請相關方參與進來,幫助團隊解決問題,同時也是為了有效地管理相關方對項目的期望。
  • 主庫n -> 從庫s - MySQL5.7多主一從(多源複製)同步配置 - 計算機...
    部署環境註:使用docker部署mysql實例,方便快速搭建演示環境。但本文重點是講解主從配置,因此簡略描述docker環境構建mysql容器實例。IP=192.168.10.212; PORT=4500; server-id=500; database=test5; table=user從庫10345:IP=192.168.10.212; PORT=4345; server-id=10345; database=test3,test4,test5; table=user配置約束主從庫必須保證網絡暢通可訪問主庫必須開啟binlog日誌主從庫的
  • 100條MySQL規範,從入門到精通,很實用!
    不同的字符集進行比較前需要進行轉換會造成索引失效3、所有表和欄位都需要添加注釋使用comment從句添加表和列的備註 從一開始就進行數據字典的維護4、儘量控制單表數據量的大小,建議控制在500萬以內500萬並不是MySQL資料庫的限制,過大會造成修改表結構,備份,恢復都會有很大的問題
  • 安裝MySQL後,需要調整的10個性能配置項
    如果你沒有調整,很可能會遇到問題。(重做日誌)的大小。在應用程式端使用連接池或者在 MySQL 端使用線程池有助於解決這個問題。如果您的 MySQL 已經啟用了查詢緩存並且從沒有發現過問題, 那麼查詢緩存可能是對你有益的,這個時候如果你想禁用它的時候應該小心操作。
  • 您的包裹「 MySQL靈魂十連」 待籤收
    主從同步流程:主節點必須啟用二進位日誌,記錄任何修改了資料庫數據的事件。從節點開啟一個線程(I/O Thread)把自己扮演成 mysql 的客戶端,通過 mysql 協議,請求主節點的二進位日誌文件中的事件 。
  • MySQL 一千個不用 Null 的理由
    點擊關註上方「SQL資料庫開發」,港真,Null 貌似在哪裡都是個頭疼的問題