1. 弊端

1.1. 取值范圍

TIMESTAMP 的取值范圍為 1970-01-01 00:00:01 UTC 到 2038-01-19 03:14:07 UTC，超出范圍的數據會被強制歸零或觸發異常?。

具體表現為在基金債券等業務中，到期日可能是一個比較晚的未來的時間，很可能就會出現超出 TIMESTAMP 范圍的時間。

現在已經 2025 年了，系統崩潰只在眨眼之間！！！

1.2. 時區依賴

存入時自動轉換為 UTC 時間，查詢時根據會話時區轉換回本地時間。若時區配置不一致，同一時間在不同服務器顯示結果不同?

1.3. 隱式轉換

存入 NULL 會自動填充為當前時間

2. 區別

?特性?	?TIMESTAMP?	?DATETIME?
?存儲機制?	整數（Unix 時間戳）	字符串（YYYY-MM-DD HH:MM:SS）
?存儲空間?	4 字節（舊版）或 7 字節（MySQL 5.6+）	8 字節
?時區處理?	自動轉換為 UTC 存儲并轉換回會話時區	無視時區，直接存儲原始值
?取值范圍?	1970-01-01 00:00:01 ~ 2038-01-19 03:14:07	1000-01-01 00:00:00 ~ 9999-12-31 23:59:59
?默認值支持?	支持 CURRENT_TIMESTAMP 自動初始化	需顯式聲明
?2038 年問題?	? 2038 年后溢出	? 無此限制
?NULL 處理?	自動填充為當前時間	保持 NULL

3. 解決

2038 年后必須遷移至 DATETIME；跨國系統優先 DATETIME 減少時區風險?。