之前因為各種原因，有些報警沒有引起重視，最近放假馬上排除了一些潛在的人為原因，發現資料庫的慢日誌報警有些奇怪，主要表現是慢日誌報警不屬實，收到報警的即時通訊提醒後，隔一會去資料庫裡面去排查，發現慢日誌的效能似乎沒有那麼差（我設定的乙個閾值是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_t程式設計客棧ime_pct_95 |
+----+-------------------+
| 1 | 8.83736 程式設計客棧 |
| 4 | 7.70056 |
| 7 | 5.09871 |
| 10 | 4.32582 |www.cppcns.com
+----+-------------------+
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 *frowww.cppcns.comm 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的優化一則
目的在於這麼乙個sql語句 select w.from wall w inner join wall category relation r on w.wall id r.wall id where r.category level1 id 39 and w.is online 1 order by...
Mysql的優化一則
目的在於這麼乙個sql語句 1 select w.from wall w inner join wall category relation r on w.wall id r.wall id where r.category level1 id 39 and w.is online 1 order ...
Mysql的優化一則
目的在於這麼乙個sql語句 select w.from wall w inner join wall category relation r on w.wall id r.wall id where r.category level1 id 39 and w.is online 1 order by...