問題描述

像這樣 1476355731 的數(shù)字

問題解答

有些人真是這么做的,可能是覺得日期類型計算太麻煩了，不如+30*60*60這樣簡單。

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

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

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

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

但要注意的是：如果用int來存儲時間戳的話，請注意int值的最大值范圍。

參考資料：

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

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

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