問(wèn)題描述

像這樣 1476355731 的數(shù)字

問(wèn)題解答

有些人真是這么做的,可能是覺(jué)得日期類型計(jì)算太麻煩了，不如+30*60*60這樣簡(jiǎn)單。

不同地區(qū)時(shí)區(qū)不一樣，如果你存?zhèn)€2016-10-14 9:40:32，在另外的時(shí)區(qū)就不對(duì)了。存成unix時(shí)間戳,容易轉(zhuǎn)換成不同時(shí)區(qū)的時(shí)間。

你要說(shuō)弊端，那就是你去直接看數(shù)據(jù)庫(kù)的時(shí)候，不知道具體的時(shí)間。

但我看過(guò)的幾乎所有討論數(shù)據(jù)庫(kù)中怎樣保存時(shí)間的文章中的觀點(diǎn)都是“使用時(shí)間戳”。

優(yōu)點(diǎn)：數(shù)據(jù)量大的時(shí)候如果需要以該字段作為查詢條件的時(shí)候查詢速度會(huì)快一點(diǎn)（在同等條件下+合理索引情況下）；缺點(diǎn)：查詢結(jié)果不直觀，需要二次處理。不過(guò)這個(gè)幾乎可以忽略，如果是在客戶端用sql查詢的時(shí)候，mysql自帶了UNIX_TIMESTAMP 和FROM_UNIXTIME 的轉(zhuǎn)換函數(shù)；如果是程序處理的話，把時(shí)間戳轉(zhuǎn)換成日期對(duì)象并不是什么特別麻煩的事情。

但要注意的是：如果用int來(lái)存儲(chǔ)時(shí)間戳的話，請(qǐng)注意int值的最大值范圍。

參考資料：

https://segmentfault.com/q/10...

數(shù)據(jù)庫(kù)內(nèi)部就是按照時(shí)間戳的機(jī)制保存的，之所以單獨(dú)定出Date類型，個(gè)人考慮是基于開(kāi)發(fā)便利性的，否則保存為數(shù)字類型，所有的日期運(yùn)算的函數(shù)都得自己實(shí)現(xiàn)。

我是比較喜歡用時(shí)間戳的，需要顯示什么樣的格式都可以自行轉(zhuǎn)換，int類型就可以滿足，不需要bigint