關於資料庫中如何儲存時間的一點思考

我記得我在大學的時候就這樣幹過，而且現在很多對資料庫不太了解的新手也會這樣幹，可見，這種儲存日期的方式的優點還是有的，就是簡單直白，容易上手。

但是，這是不正確的做法，主要會有下面兩個問題：

字串占用的空間更大！

字串儲存的日期比較效率比較低（逐個字元進行比對），無法用日期相關的 api 進行計算和比較。

datetime 和 timestamp 是 mysql 提供的兩種比較相似的儲存時間的資料型別。他們兩者究竟該如何選擇呢？

通常我們都會首選 timestamp。下面說一下為什麼這樣做!

2.1 datetime 型別沒有時區資訊的

datetime 型別是沒有時區資訊的（時區無關），datetime 型別儲存的時間都是當前會話所設定的時區對應的時間。這樣就會有什麼問題呢？當你的時區更換之後，比如你的伺服器更換位址或者更換客戶端連線時區設定的話，就會導致你從資料庫中讀出的時間錯誤。不要小看這個問題，很多系統就是因為這個問題鬧出了很多笑話。

timestamp 和時區有關。timestamp 型別欄位的值會隨著伺服器時區的變化而變化，自動換算成相應的時間，說簡單點就是在不同時區，查詢到同乙個條記錄此字段的值會不一樣。

下面實際演示一下！

建表 sql 語句：

create table `time_zone_test` (
`id` bigint(20) not null auto_increment,
`date_time` datetime default null,
`time_stamp` timestamp not null default current_timestamp on update current_timestamp,
primary key (`id`)
) engine=innodb default charset=utf8;

插入資料：

insert into time_zone_test(date_time,time_stamp) values(now(),now());

檢視資料：

select date_time,time_stamp from time_zone_test;

結果：

+---------------------+---------------------+
| date_time | time_stamp |
+---------------------+---------------------+
| 2020-01-11 09:53:32 | 2020-01-11 09:53:32 |
+---------------------+---------------------+

現在我們執行

修改當前會話的時區:

set time_zone='+8:00';

再次檢視資料：

+---------------------+---------------------+
| date_time | time_stamp |
+---------------------+---------------------+
| 2020-01-11 09:53:32 | 2020-01-11 17:53:32 |
+---------------------+---------------------+

擴充套件：一些關於 mysql 時區設定的乙個常用 sql 命令

# 檢視當前會話時區
select @@session.time_zone;
# 設定當前會話時區
set time_zone = 'europe/helsinki';
set time_zone = "+00:00";
# 資料庫全域性時區設定
select @@global.time_zone;
# 設定全域性時區
set global time_zone = '+8:00';
set global time_zone = 'europe/helsinki';

2.2 datetime 型別耗費空間更大

timestamp 只需要使用 4 個位元組的儲存空間，但是 datetime 需要耗費 8 個位元組的儲存空間。但是，這樣同樣造成了乙個問題，timestamp 表示的時間範圍更小。

timestamp 在不同版本的 mysql 中有細微差別。

下圖是 mysql 5.6 版本中日期型別所佔的儲存空間：

可以看出 5.6.4 之後的 mysql 多出了乙個需要 0 ～ 3 位元組的小數字。datatime 和 timestamp 會有幾種不同的儲存空間占用。

為了方便，本文我們還是預設 timestamp 只需要使用 4 個位元組的儲存空間，但是 datetime 需要耗費 8 個位元組的儲存空間。

很多時候，我們也會使用 int 或者 bigint 型別的數值也就是時間戳來表示時間。

這種儲存方式的具有 timestamp 型別的所具有一些優點，並且使用它的進行日期排序以及對比等操作的效率會更高，跨系統也很方便，畢竟只是存放的數值。缺點也很明顯，就是資料的可讀性太差了，你無法直觀的看到具體時間。

時間戳的定義如下：

時間戳的定義是從乙個基準時間開始算起，這個基準時間是「1970-1-1 00:00:00 +0:00」，從這個時間開始，用整數表示，以秒計時，隨著時間的流逝這個時間整數不斷增加。這樣一來，我只需要乙個數值，就可以完美地表示時間了，而且這個數值是乙個絕對數值，即無論的身處地球的任何角落，這個表示時間的時間戳，都是一樣的，生成的數值都是一樣的，並且沒有時區的概念，所以在系統的中時間的傳輸中，都不需要進行額外的轉換了，只有在顯示給使用者的時候，才轉換為字串格式的本地時間。

資料庫中實際操作：

mysql> select unix_timestamp('2020-01-11 09:53:32');
+---------------------------------------+
| unix_timestamp('2020-01-11 09:53:32') |
+---------------------------------------+
| 1578707612 |
+---------------------------------------+
1 row in set (0.00 sec)
mysql> select from_unixtime(1578707612);
+---------------------------+
| from_unixtime(1578707612) |
+---------------------------+
| 2020-01-11 09:53:32 |
+---------------------------+
1 row in set (0.01 sec)

mysql 中時間到底怎麼儲存才好？datetime?timestamp? 數值儲存的時間戳？

好像並沒有乙個銀彈，很多程式設計師會覺得數值型時間戳是真的好，效率又高還各種相容，但是很多人又覺得它表現的不夠直觀。這裡插一嘴，《高效能 mysql 》這本神書的作者就是推薦 timestamp，原因是數值表示時間不夠直觀。下面是原文：

每種方式都有各自的優勢，根據實際場景才是王道。下面再對這三種方式做乙個簡單的對比，以供大家實際開發中選擇正確的存放時間的資料型別：

關於資料庫中如何儲存時間的一點思考

關於資料庫索引的一點理解

關於資料庫索引的一點理解

資料庫如何儲存時間

關於資料庫中如何儲存時間的一點思考

關於資料庫索引的一點理解

關於資料庫索引的一點理解

資料庫如何儲存時間

相關推薦