在優化索引時，思考了一個問題，DATE, DATETIME, TIMESTAMP，還有INT存儲的時間，在索引中哪個效率更高一些？
索引存儲的，如果單純的測試，而不去了解底層存儲的方式和類型就不能斷言哪個類型的效率更好一些。
DATE: （YYYY-MM-DD） 范圍 '1000-01-01' to '9999-12-31' .DATETIME: （YYYY-MM-DD HH:MM:SS） 范圍 '1000-01-01 00:00:00' to '9999-12-31 23:59:59'. 支持自動更新TIMESTAMP: （YYYY-MM-DD HH:MM:SS）范圍 '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC. 支持自動更新-
INT： (整數) 范圍 '1970-01-01 00:00:01' to '2038-01-19 03:14:07'
（這里 DATETIME，TIMESTAMP都支持0-6位的時間精度，這里就不講了）
注意 TIMESTAMP 會先將用戶輸入轉換成UTC時間進行存儲，查詢時也會將時間轉換成當前UTC時間，所以當數據庫服務器的時區跟查詢客戶端時區不一致時，會出現查詢不到的情況。
再看MYSQL對這個幾個類型的存儲情況。
| 類型 | before MySQL 5.6.4 | Storage as of MySQL 5.6.4 |
|---|---|---|
| DATE | 3 bytes, 小端字節 | 3 bytes, 小端字節 |
| DATE | 3 bytes, 小端字節 | 3 bytes, 小端字節 |
| TIMESTAMP | 4 bytes, 小端字節 | 4 bytes + 毫秒存儲, 大端字節 |
| DATETIME | 8 bytes, 小端字節 | 5 bytes + 毫秒存儲, 大端字節 |
| INT | 4 bytes | 4 bytes |
- DATE : 3個字節整型 YYYY×16×32 + MM×32 + DD
- TIMESTAMP : 4個字節整型，存儲UTC時間秒。
- DATETIME:
1.（5.6.4 之前）8個字節， 其中4個字節整型 YYYY×10000 + MM×100 + DD 和 4個字節整型HH×10000 + MM×100 + SS
2.（5.6.4 之后）
1 bit 符號位 (1= 整數, 0=負數)
17 bits year*13+month (year 0-9999, month 0-12)
5 bits day (0-31)
5 bits hour (0-23)
6 bits minute (0-59)
6 bits second (0-59)
---------------------------
40 bits = 5 bytes
- INT 4個字節整型，存儲時間秒
毫秒存儲位
| 精度 | 存儲空間 |
|---|---|
| 0 | bytes |
| 1，2 | 1 bytes |
| 3，4 | 2 bytes |
| 4，6 | 3 bytes |
對各個時間類型有個整體的了解以后我們分析一下。
其中DATE字段精度不夠不參與對比。
對比一下 DATETIME 、 TIMESTAMP、 INT
- 從存儲時間范圍看 DATETIME > TIMESTAMP = INT
- 從使用方便上看 帶有自動更新 DATETIME , TIMESTAMP > INT
- 從時間精度看 DATETIME > TIMESTAMP > INT
- 從存儲空間上看,同一精度下DATETIME > TIMESTAMP = INT
- 從查詢速度上看，底層都是整型存儲，所以 DATETIME = TIMESTAMP = INT
不考慮存儲空間優化的情況下，DATETIME是最優的時間存儲類型
考慮存儲空間的情況下，TIMESTAMP是最優的時間存儲類型
參考文檔
https://dev.mysql.com/doc/refman/8.0/en/datetime.html
https://dev.mysql.com/doc/internals/en/date-and-time-data-type-representation.html
