datetime： 

1、儲存格式為YYYYMMDDHHMMSS（年月日時分秒）的整數，所以，它與時區無關，存入的是什麼值就是什麼值，不會根據當前時區進行轉換。

2、從mysql 5.6.4中，可以儲存小數片段，最多到小數點後6位，顯示時格式為 yyyy-MM-dd HH:mm:ss[.222222]

      mysql5.5中，沒有小數片段，精確到秒。所以，我再從5.6版本遷移到5.5版本時，因為生成的sql中datetime(6),所以無法匯入資料庫。

3、儲存範圍：從1000-01-01 00:00:00 到'9999-12-31 23:59:59'

4、長度，8個位元組，datetime(n),n不是儲存長度，而是顯示的小數位數，即使小數位數是0，儲存是也是儲存的6位小數，僅僅顯示0位而已

5、顯示時，顯示日期和時間

timestamp：

1、存入的是自1970-01-01午夜(格林尼治標準時間)以來的秒數，它和unix時間戳相同。所以它與時區有關，查詢時轉為相應的時區時間。比如，儲存的是1970-01-01 00:00:00，客戶端是北京，那麼就加8個時區的小時1970-01-01 08:00:00。

2、有小數片段，至少從5.5就開始有

3、儲存範圍：'1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07'

4、可以當做時間戳使用，在更新時，自動更新，這一列只能由系統自動更新，不能由sql更新，這個在樂觀鎖時有廣泛的應用

6、長度，4位元組，因為儲存長度的原因，決定了它支援的範圍的比datetime的要小

7、顯示時，顯示日期和時間

date

date，時分秒都儲存了，但只顯示日期。對應Java中的java.sql.Date

datetime與時區無關、timestamp與時區有關

1、檢視當前時區，並建立表test_date,一個是timestamp列，一個是datetime列

2、插入兩條資料，相同的時間。修改時區為0時區（格林尼治時區）後，檢視時間，發現timestamp改變了，datetime沒變。

總結

datetime、timestamp精確度都是秒，datetime與時區無關，儲存的範圍廣(1001-9999)，timestamp與時區有關，儲存的範圍小(1970-2038)。