使用MYSQL TIMESTAMP字段進行時間加減運算問題
MYSQL TIMESTAMP字段進行時間加減運算
在數(shù)據(jù)分析過程中,想當然地對TIMESTAMP字段進行運算,導致結果謬之千里
計算公式如下
-- create_time與week_time的聲明都是TIMESTAMP(), 要求精確到分鐘 -- SELECT (sa.create_time - sa.week_time)/(1000 * 60) from alarm_sla_1 sa
當然正確的解法是利用timestampdiff函數(shù),如下:
SELECT timestampdiff(minute, sa.create_time, sa.week_time) from alarm_sla_1 sa
但有意思的問題在于,MYSQL明明支持減法操作,為何操作的結果又大相徑庭?
類似的問題還有,TIMESTAMP字段的時間精度是什么?
從MYSQL的官方實例中可以看到(請見后續(xù)的參考文檔),TIMESTAMP字段的小數(shù)部分確定了秒的經度,3位小數(shù)精確到毫秒,6位小數(shù)精確到微秒,如下:
| 聲明方式 | 小數(shù)長度 | 精度 |
|---|---|---|
| TIMESTAMP(3) | 3 | 毫秒 |
| TIMESTAMP(6) | 6 | 微秒 |
按照上面的推論,那么默認的聲明TIMESTAMP應該精確到秒,那么應該相減的結果應該得到秒,測試語句如下:
SELECT sa.week_time - sa.create_time, timestampdiff(second, sa.create_time, sa.week_time) from alarm_sla_1 sa
但最后的結果見下表:
| 相減結果 | 函數(shù)結果 |
|---|---|
| 1000012 | 86412 |
顯然,并不存在相關性,差異何止里計?
后來繼續(xù)進行了指定經度的操作運算,結論依舊如此。
DATETIME 與 TIMESTAMP的區(qū)別
| 特性 | DATETIME | TIMESTAMP |
|---|---|---|
| 時間范圍 | 1000-01-01 00:00:00到9999-12-31 23:59:59 | 1970-01-01 00:00:01到2038-01-09 03:14:07 |
| 存儲空間 | 8+3(秒的精度) | 4+3(秒的精度) |
| 格式轉換 | 不支持 | 支持UTC |
| 多時區(qū)支持 | 不支持,固定時區(qū) | 不支持 |
| 創(chuàng)建索引 | 不能 | 能 |
| 查詢后緩存結果 | 否 | 是 |
結論
MYSQL中TIMESTAMP字段直接進行相減操作,可能得到難以理解的結果,請慎用。
以上為個人經驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
參考文檔
相關文章
MySQL在Centos7環(huán)境安裝的完整步驟記錄
在CentOS7環(huán)境下安裝MySQL是一項常見的任務,尤其對于那些沒有網絡連接或者需要在隔離環(huán)境中的開發(fā)者來說,離線安裝MySQL顯得尤為重要,這篇文章主要介紹了MySQL在Centos7環(huán)境安裝的完整步驟,需要的朋友可以參考下2024-10-10
mysql8.0.20配合binlog2sql的配置和簡單備份恢復的步驟詳解
這篇文章主要介紹了mysql8.0.20配合binlog2sql的配置和簡單備份恢復的步驟,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-09-09
坑人的Mysql5.7問題(默認不支持Group By語句)
這篇文章主要介紹了坑人的Mysql5.7問題(默認不支持Group By語句),具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-10-10
macOS Sierra安裝Apache2.4+PHP7.0+MySQL5.7.16
這篇文章主要為大家詳細介紹了macOS Sierra安裝Apache2.4+PHP7.0+MySQL5.7.16的相關資料,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-01-01
mysql中整數(shù)數(shù)據(jù)類型tinyint詳解
大家好,本篇文章主要講的是mysql中整數(shù)數(shù)據(jù)類型tinyint詳解,感興趣的同學趕快來看一看吧,對你有幫助的話記得收藏一下,方便下次瀏覽2021-12-12

