timestamp在mysql中定義的是int類型的數(shù)據(jù)，然后1970年到2038年的秒數(shù)剛好21億，為了限制，所以只能截止到2038年。雖然現(xiàn)在可以設(shè)置數(shù)字精度了 但是數(shù)據(jù)精度提高的代價(jià)是其內(nèi)部存儲(chǔ)空間的變大，但仍未改變時(shí)間戳類型的最小和最大取值范圍。
**但是我覺得吧 隨著時(shí)間臨近，mysql會(huì)更新的。**而且還有這么多年呢 肯定也會(huì)有其他東西取代他

此外還有語(yǔ)言提供的字符串類型，10位（精確到秒）或13位（精確到毫秒）。其中13位必須bigint存儲(chǔ)，占用8字節(jié)，而且在顯示的時(shí)候，mysql不會(huì)自動(dòng)轉(zhuǎn)成我們常見的日期格式，所以不推薦使用。

如何存儲(chǔ)毫秒或者更高級(jí)別的小數(shù)？

意思就是，毫秒部分需要以參數(shù)形式傳參給數(shù)據(jù)類型，默認(rèn)是不保存毫秒的，可以保存1-6位。如果需要保存三位的毫秒值，數(shù)據(jù)類型可以定義為DATETIME(3)或TIMESTAMP(3)，不需要保存毫秒的話，只需要將類型直接寫為DATETIME TIMESTAMP。

時(shí)間戳詳解

一個(gè)方便的用法

在創(chuàng)建新記錄和修改現(xiàn)有記錄的時(shí)候都對(duì)這個(gè)數(shù)據(jù)列刷新：（datetime也能用）

TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

顯示格式（非存儲(chǔ)格式）

TIMESTAMP值可以從1970的某時(shí)的開始一直到2037年，精度為一秒，其值作為數(shù)字顯示。
TIMESTAMP值顯示尺寸的格式如下表所示：

+---------------+----------------+
| 列類型　　　　| 顯示格式　　　 |
| TIMESTAMP(14) | YYYYMMDDHHMMSS |　
| TIMESTAMP(12) | YYMMDDHHMMSS　 |
| TIMESTAMP(10) | YYMMDDHHMM　　 |
| TIMESTAMP(8)　| YYYYMMDD　　　 |
| TIMESTAMP(6)　| YYMMDD　　　　 |
| TIMESTAMP(4)　| YYMM　　　　　 |
| TIMESTAMP(2)　| YY　　　　　　 |
+---------------+----------------+

“完整”TIMESTAMP格式是14位，但TIMESTAMP列也可以用更短的顯示尺寸，創(chuàng)造最常見的顯示尺寸是6、8、12、和14。
你可以在創(chuàng)建表時(shí)指定一個(gè)任意的顯示尺寸，但是定義列長(zhǎng)為0或比14大均會(huì)被強(qiáng)制定義為列長(zhǎng)14。
列長(zhǎng)在從1～13范圍的奇數(shù)值尺寸均被強(qiáng)制為下一個(gè)更大的偶數(shù)。
這有以下含義

• 雖然你建表時(shí)定義了列TIMESTAMP(8)，但在你進(jìn)行數(shù)據(jù)插入與更新時(shí)TIMESTAMP列實(shí)際上保存了14位的數(shù)據(jù)（包括年月日時(shí)分秒），只不過在你進(jìn)行查詢時(shí)MySQL返回給你的是8位的年月日數(shù)據(jù)。如果你使用ALTER TABLE拓寬一個(gè)狹窄的TIMESTAMP列，以前被“隱蔽”的信息將被顯示。
• 同樣，縮小一個(gè)TIMESTAMP列不會(huì)導(dǎo)致信息失去，除了感覺上值在顯示時(shí)，較少的信息被顯示出。
• 盡管TIMESTAMP值被存儲(chǔ)為完整精度，直接操作存儲(chǔ)值的唯一函數(shù)是UNIX_TIMESTAMP()；由于MySQL返回TIMESTAMP列的列值是進(jìn)過格式化后的檢索的值，這意味著你可能不能使用某些函數(shù)來操作TIMESTAMP列（例如HOUR()或SECOND()），除非TIMESTAMP值的相關(guān)部分被包含在格式化的值中。
• 例如，一個(gè)TIMESTAMP列只有被定義為TIMESTAMP(10)以上時(shí)，TIMESTAMP列的HH部分才會(huì)被顯示，因此在更短的TIMESTAMP值上使用HOUR()會(huì)產(chǎn)生一個(gè)不可預(yù)知的結(jié)果。
• 不合法TIMESTAMP值被變換到適當(dāng)類型的“零”值(00000000000000)。（DATETIME,DATE亦然）

java可能遇到的坑

詳情請(qǐng)看原文：原文鏈接：http://m.fzitv.net/article/255355.htm
送 sql 前，會(huì)將 jdbc 中的 Date 對(duì)象參數(shù)，根據(jù) serverTimeZone 配置的時(shí)區(qū)轉(zhuǎn)化為日期字符串后，再發(fā)送 sql 請(qǐng)求給 mysql server，同樣在 mysql server 返回查詢結(jié)果后，結(jié)果中的日期值也是日期字符串，mysql 驅(qū)動(dòng)會(huì)根據(jù) serverTimeZone 配置的時(shí)區(qū)，將日期字符串轉(zhuǎn)化為 Date 對(duì)象。

因此，當(dāng) serverTimeZone 與數(shù)據(jù)庫(kù)實(shí)際時(shí)區(qū)不一致時(shí)，會(huì)發(fā)生時(shí)區(qū)轉(zhuǎn)換錯(cuò)誤，導(dǎo)致時(shí)間偏差，如下：

a、比如 sql 參數(shù)是一個(gè) Date 對(duì)象，時(shí)間值是東 8 區(qū)的2020-02-23 08:00:00，注意它里面存儲(chǔ)的可不是2020-02-23 08:00:00這個(gè)字符串，它是 Date 對(duì)象(絕對(duì)時(shí)間)，只是我用文字表達(dá)出來是東 8 區(qū)的2020-02-23 08:00:00。

b、然后，由于 serverTimeZone 配置的是東 8 區(qū)，mysql 驅(qū)動(dòng)會(huì)將這個(gè) Date 對(duì)象轉(zhuǎn)為2020-02-23 08:00:00，注意這時(shí)已經(jīng)是字符串了，然后再將 sql 發(fā)送給 mysql，注意這里的 sql 里面已經(jīng)將 Date 參數(shù)替換為2020-02-23 08:00:00了，因?yàn)?Date 對(duì)象本身是無法走網(wǎng)絡(luò)的。

c、然后 mysql 數(shù)據(jù)庫(kù)接收到這個(gè)時(shí)間字符串2020-02-23 08:00:00后，由于數(shù)據(jù)庫(kù)時(shí)區(qū)配置是東 9 區(qū)，它會(huì)認(rèn)為這個(gè)時(shí)間是東 9 區(qū)的，它會(huì)以東 9 區(qū)解析這個(gè)時(shí)間字符串，這時(shí)數(shù)據(jù)庫(kù)保存的時(shí)間是東9區(qū)的2020-02-23 08:00:00，也就是東8區(qū)的2020-02-23 07:00:00，保存的時(shí)間就偏差了 1 個(gè)小時(shí)。

d、查詢結(jié)果里時(shí)間為什么又對(duì)了呢，因?yàn)椴樵兘Y(jié)果返回了東 9 區(qū)的時(shí)間字符串，而 java 應(yīng)用又將其理解為是東 8 區(qū)的時(shí)間，負(fù)負(fù)得正了！

時(shí)間戳查詢的時(shí)候 能否返回原生的時(shí)間戳呢

到此這篇關(guān)于淺談Mysql時(shí)間的存儲(chǔ) datetime還是時(shí)間戳timestamp的文章就介紹到這了,更多相關(guān)Mysql時(shí)間的存儲(chǔ) 內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！