一次線上事故，讓我對MySql的時間戳存char(10)還是int(10)有了全新的認識

奔四少年發表於2021-05-28
MySql時間戳

美好的週五

週五的早晨，一切都是那麼美好。

 

然鵝，10點多的時候，運營小哥哥突然告訴我後臺打不開了，我懷著一顆“有什麼大不了的，估計又是（S）（B）不會連wifi”的心情，自信的開啟了網址，果然，真打不開了。

這是存心讓我過不好週末呀！

 

抓住那隻bug

經過我縝密的排查，發現是一個“獲取今天之前登入的使用者”介面呼叫嚴重超時：

一次線上事故，讓我對MySql的時間戳存char(10)還是int(10)有了全新的認識

這個介面其實呼叫的資料表不多，在mysql只讀取了1張表，表結構如下：

 

 

獲取今天之前登入的使用者列表的SQL如下：

SELECT u.email, log.user_id
FROM `user` u
LEFT JOIN `log_user_active` log ON u.user_id = log.user_id
WHERE log.`log_dtime` <1634567890
LIMIT 0 , 30

 

 這只是一個簡單的sql查詢，並沒有什麼高精尖、複雜的查詢為什麼這麼慢？由於log_user_active的資料量最大，所以猜想應該是log_user_active表出了問題，為了排查原因，我把SQL又簡化了下，去掉了JOIN直接簡化為：

SELECT log.user_id
FROM `log_user_active`
WHERE `log_dtime` <1551784072
LIMIT 0 , 30

經執行，這個語句花了將近1秒。。。如果多人同時訪問，MySql不崩潰才怪。

此時，應該確信是這個表出問題無疑了，但是欄位log_dtime明明建立了索引，怎麼還這麼慢呢？

經過各種百度，終於發現問題所在：由於log_dtime設計的是char型別。如果想讓他走索引，查詢的時候值必須要加引號，說明這是個字串，否則是不會走索引的。我的資料恰巧都是數字組成（時間戳），查詢的時候也沒有刻意去加引號，導致查詢的時候不走索引。

這就是問題所在了，於是進行如下嘗試：

嘗試1：

SQL的值加上引號

 

如上圖，果然極快。

但是這樣的話，需要改好多程式碼，我想想還是嘗試下方法2吧。

嘗試2：

果斷將資料表結構log_dtime設計為INT型，如圖：

 

 再次執行SQL：

SELECT log.user_id
FROM `log_user_active`
WHERE `log_dtime` <1551784072
LIMIT 0 , 30

相應結果提升N倍：

 

 至此，問題處理完畢。

總結

char型別欄位想走索引的話，必須用引號括起來。如果是時間戳等型別的純數字，建議還是存為int型吧。

愉快的週末，又向我招手了。

 

相關文章