mysql数据库时间类型数据存储建议
不使用字符串存储日期
使用字符串存储日期的缺点:字符串占用的空间更大;字符串存储的日期效率比较低,无法用日期相关的 API 进行计算和比较。
Datetime 和 Timestamp
首选 Timestamp:DateTime 类型没有时区信息,DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。当时区更换之后就会导致从数据库中读出的时间错误。DateTime 类型耗费空间更大。Timestamp 和时区有关,Timestamp类型字段的值会随着服务器时区的变化而变化,自动换算成相应的时间。因此在不同时区查询到同一个条记录此字段的值会不一样。
建表
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 时区设置的常用命令
# 查看当前会话时区
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'
DateTime 类型耗费空间更大:Timestamp 只需要使用 4 个字节的存储空间,但是 DateTime 需要耗费 8 个字节的存储空间。但是这样同样造成了一个问题,Timestamp 表示的时间范围更小。Timestamp 在不同版本的 MySQL 中有细微差别。
- DateTime :1000-01-01 00:00:00 ~ 9999-12-31 23:59:59
- Timestamp: 1970-01-01 00:00:01 ~ 2037-12-31 23:59:59
数值型时间戳
有时我们也会使用 int 或者 bigint 类型的数值来表示时间。这种存储方式的具有 Timestamp 类型的所具有一些优点,并且使用它的进行日期排序以及对比等操作的效率会更高,跨系统也很方便,毕竟只是存放的数值。缺点也很明显,就是数据的可读性差了,无法直观的看到具体时间。
时间戳的定义如下:时间戳是从一个基准时间开始算起,这个基准时间是「1970-1-1 00:00:00 +0:00」,从这个时间开始,用整数表示,以秒计时,随着时间的流逝这个时间整数不断增加。这样一来只需要一个数值,就可以完美地表示时间了,而且这个数值是一个绝对数值,即无论的身处地球的任何角落,这个表示时间的时间戳都是一样的,生成的数值都是一样的,并且没有时区的概念,所以在系统的中时间的传输中,都不需要进行额外的转换了,只有在显示给用户的时候,才转换为字符串格式的本地时间。
数据库中实际操作:
mysql> select UNIX_TIMESTAMP('2020-01-11 09:53:32');
1578707612
mysql> select FROM_UNIXTIME(1578707612);
2020-01-11 09:53:32
浙公网安备 33010602011771号