目錄

• MYSQL TIMESTAMP字段進(jìn)行時(shí)間加減運(yùn)算
• 計(jì)算公式如下
• DATETIME 與 TIMESTAMP的區(qū)別
• 結(jié)論
• 參考文檔

MYSQL TIMESTAMP字段進(jìn)行時(shí)間加減運(yùn)算

在數(shù)據(jù)分析過(guò)程中，想當(dāng)然地對(duì)TIMESTAMP字段進(jìn)行運(yùn)算，導(dǎo)致結(jié)果謬之千里

計(jì)算公式如下

-- create_time與week_time的聲明都是TIMESTAMP(), 要求精確到分鐘 --
SELECT (sa.create_time - sa.week_time)/(1000 * 60)
from alarm_sla_1 sa

當(dāng)然正確的解法是利用timestampdiff函數(shù)，如下：

SELECT timestampdiff(minute, sa.create_time, sa.week_time)
from alarm_sla_1 sa

但有意思的問(wèn)題在于，MYSQL明明支持減法操作，為何操作的結(jié)果又大相徑庭？

類似的問(wèn)題還有，TIMESTAMP字段的時(shí)間精度是什么？

從MYSQL的官方實(shí)例中可以看到（請(qǐng)見(jiàn)后續(xù)的參考文檔），TIMESTAMP字段的小數(shù)部分確定了秒的經(jīng)度，3位小數(shù)精確到毫秒，6位小數(shù)精確到微秒，如下：

聲明方式小數(shù)長(zhǎng)度精度TIMESTAMP(3)3毫秒TIMESTAMP(6)6微秒

按照上面的推論，那么默認(rèn)的聲明TIMESTAMP應(yīng)該精確到秒，那么應(yīng)該相減的結(jié)果應(yīng)該得到秒，測(cè)試語(yǔ)句如下：

SELECT sa.week_time - sa.create_time, timestampdiff(second, sa.create_time, sa.week_time)
from alarm_sla_1 sa

但最后的結(jié)果見(jiàn)下表：

相減結(jié)果函數(shù)結(jié)果100001286412

顯然，并不存在相關(guān)性，差異何止里計(jì)？

后來(lái)繼續(xù)進(jìn)行了指定經(jīng)度的操作運(yùn)算，結(jié)論依舊如此。

DATETIME 與 TIMESTAMP的區(qū)別

特性DATETIMETIMESTAMP時(shí)間范圍1000-01-01 00:00:00到9999-12-31 23:59:591970-01-01 00:00:01到2038-01-09 03:14:07存儲(chǔ)空間8+3(秒的精度)4+3(秒的精度)格式轉(zhuǎn)換不支持支持UTC多時(shí)區(qū)支持不支持，固定時(shí)區(qū)不支持創(chuàng)建索引不能能查詢后緩存結(jié)果否是

結(jié)論

MYSQL中TIMESTAMP字段直接進(jìn)行相減操作，可能得到難以理解的結(jié)果，請(qǐng)慎用。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持。

參考文檔

• 日期與時(shí)間函數(shù)
• 秒的精度說(shuō)明