MySQL时间存储的类型选择

最新推荐文章于 2022-10-11 15:14:01 发布

Lens5935

最新推荐文章于 2022-10-11 15:14:01 发布

阅读量431

点赞数

分类专栏： MySQL 文章标签： mysql 数据库

本文链接：https://blog.csdn.net/weixin_40983094/article/details/118495161

版权

MySQL 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

本文讨论了数据库中存储时间的常见错误，如使用字符串，以及DateTime和Timestamp的选择。推荐使用Timestamp，因为它与时区相关，能自动调整。尽管DateTime在某些情况下可能更直观，但其占用更多空间且不处理时区。数值型时间戳也是一个选项，虽然节省空间且排序高效，但可读性较差。在考虑存储时间时，应权衡空间、效率和可读性。

摘要由CSDN通过智能技术生成

平时开发中不可避免的就是要存储时间，比如我们要记录操作表中这条记录的时间等等，用的好与不好会给我们的业务甚至功能带来很大的影响。

1.切记不要用字符串存储日期

这种存储日期的方式的优点还是有的，就是简单直白，容易上手。

但是，这是不正确的做法，主要会有下面两个问题：

字符串占用的空间更大；
字符串存储的日期效率比较低（逐个字符进行比对），无法用日期相关的 API 进行计算和比较。

2.Datetime 和 Timestamp 用法选择

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          |

+---------------------+---------------------+

| 2021-06-11 09:53:32 | 2021-06-11 09:53:32 |

+---------------------+---------------------+

现在我们修改当前会话的时区:

set time_zone='+8:00';

再次查看数据：

+---------------------+---------------------+

| date_time           | time_stamp          |

+---------------------+---------------------+

| 2020-06-11 09:53:32 | 2020-06-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 中有细微差别）

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

3 MySQL 日期类型存储空间

Timestamp 只需要使用 4 个字节的存储空间，但是 DateTime 需要耗费 8 个字节的存储空间

4.数值型时间戳是更好的选择吗？

我们也会使用 int 或者 bigint 类型的数值也就是时间戳来表示时间。

这种存储方式的具有 Timestamp 类型的所具有一些优点，并且使用它的进行日期排序以及对比等操作的效率会更高，跨系统也很方便，毕竟只是存放的数值。缺点也很明显，就是数据的可读性太差了，你无法直观的看到具体时间。

时间戳的定义：

时间戳的定义是从一个基准时间开始算起，这个基准时间是「1970-1-1 00:00:00 +0:00」，从这个时间开始，用整数表示，以秒计时，随着时间的流逝这个时间整数不断增加。这样一来，我只需要一个数值，就可以完美地表示时间了，而且这个数值是一个绝对数值，即无论的身处地球的任何角落，这个表示时间的时间戳，都是一样的，生成的数值都是一样的，并且没有时区的概念，所以在系统的中时间的传输中，都不需要进行额外的转换了，只有在显示给用户的时候，才转换为字符串格式的本地时间。

数据库中实际操作：

mysql> select UNIX_TIMESTAMP('2020-06-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-06-11 09:53:32       |

+---------------------------+

1 row in set (0.01 sec)

总结：

参考：

https://github.com/Snailclimb/JavaGuide/blob/master/docs/database/%E5%85%B3%E4%BA%8E%E6%95%B0%E6%8D%AE%E5%BA%93%E5%AD%98%E5%82%A8%E6%97%B6%E9%97%B4%E7%9A%84%E4%B8%80%E7%82%B9%E6%80%9D%E8%80%83.md