您好,登錄后才能下訂單哦!
在MySQL 中日志監(jiān)控出現(xiàn)報(bào)錯(cuò)如何解決?針對(duì)這個(gè)問(wèn)題,這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答,希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。
代碼層面是類似如下的邏輯:
MySQL_slowlog_sql_history.objects.filter(create_time__gt='2020-01-29 11:00:00',Query_time_pct_95__gt=60)
傳入的時(shí)間是動(dòng)態(tài)的,然后閾值取60秒,按照預(yù)期如果報(bào)警出來(lái)就肯定是有問(wèn)題的。
為了進(jìn)一步驗(yàn)證,我把閾值時(shí)間修改為600,竟然還是報(bào)出錯(cuò)誤,執(zhí)行7~8秒的慢查詢照樣會(huì)報(bào)出來(lái)。
我使用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沒問(wèn)題啊。
我自己在客戶端執(zhí)行,確實(shí)是好好的,只過(guò)濾出了600秒以上的結(jié)果。
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;
對(duì)著這個(gè)結(jié)果我開始反思,到底是什么原因呢?
我看著模型的字段定義開始有所悟,然后快速驗(yàn)證了一番。
為了方便說(shuō)明,我創(chuàng)建了一個(gè)測(cè)試表test_dummy.
create table test_dummy(id int primary key auto_increment,Query_time_pct_95 varchar(100));
初始化幾條數(shù)據(jù)。
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)
然后使用如下的兩條語(yǔ)句來(lái)進(jìn)行對(duì)比測(cè)試。
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)
可以看到,使用了整型數(shù)值的時(shí)候,沒有返回結(jié)果,而使用了字符類型的時(shí)候,匹配的結(jié)果是按照最左匹配的模式來(lái)進(jìn)行過(guò)濾的,也就意味著在數(shù)據(jù)庫(kù)層面對(duì)于浮點(diǎn)數(shù)的處理還是差別很大的。
所以這個(gè)問(wèn)題的快速修復(fù)方式就是在數(shù)據(jù)庫(kù)層面修改數(shù)據(jù)表的類型為float,而在精度損失方面這塊的影響是可以忽略不計(jì)的。
再次驗(yàn)證,這個(gè)問(wèn)題就沒有再次出現(xiàn)。
關(guān)于在MySQL 中日志監(jiān)控出現(xiàn)報(bào)錯(cuò)如何解決問(wèn)題的解答就分享到這里了,希望以上內(nèi)容可以對(duì)大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。