时间类型

时间类型#

MySQL 提供了多种时间数据类型，用于存储日期、时间和它们的组合。每种类型都有其特定的用途和格式。以下是 MySQL 中常用的时间数据类型及其详细说明：

1. DATE#

  • 描述：存储日期值，格式为 YYYY-MM-DD。
  • 范围：1000-01-01 到 9999-12-31。
  • 示例：
    CREATE TABLE events (
    id INT AUTO_INCREMENT PRIMARY KEY,
    event_date DATE
);

2. TIME#

  • 描述：存储时间值，格式为 HH:MM:SS 或 HHH:MM:SS（对于超过一天的时间）。
  • 范围：'-838:59:59' 到 '838:59:59'。
  • 示例：
    CREATE TABLE schedules (
    id INT AUTO_INCREMENT PRIMARY KEY,
    start_time TIME
);

3. DATETIME#

  • 描述：存储日期和时间值，格式为 YYYY-MM-DD HH:MM:SS。
  • 范围：'1000-01-01 00:00:00' 到 '9999-12-31 23:59:59'。
  • 示例：
    CREATE TABLE logs (
    id INT AUTO_INCREMENT PRIMARY KEY,
    log_datetime DATETIME
);

4. TIMESTAMP#

  • 描述：存储日期和时间值，格式为 YYYY-MM-DD HH:MM:SS。TIMESTAMP 类型有以下特点：
    • 存储空间较小，占用 4 字节。
    • 自动记录当前时间戳（如果表中有多个 TIMESTAMP 列，则只有第一个会自动更新）。
    • 范围从 '1970-01-01 00:00:01' UTC 到 '2038-01-19 03:14:07' UTC。
  • 示例：
    CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

5. YEAR#

  • 描述：存储年份值，有两种格式：
    • YEAR(2)：两位数字表示年份（如 19 表示 2019 年），但不推荐使用。
    • YEAR(4)：四位数字表示年份（如 2019），这是默认格式。
  • 范围：1901 到 2155，以及 0000。
  • 示例：
    CREATE TABLE records (
    id INT AUTO_INCREMENT PRIMARY KEY,
    birth_year YEAR
);

6. TIMESTAMP 和 DATETIME 的区别#

  • 存储大小：

    • TIMESTAMP 占用 4 字节。
    • DATETIME 占用 8 字节。

  • 时区处理：

    • TIMESTAMP 值是基于 UTC 存储的，并根据系统的时区设置进行转换。
    • DATETIME 值是直接按本地时间存储，不考虑时区。

  • 自动更新：

    • TIMESTAMP 可以设置为自动更新到当前时间戳。
    • DATETIME 没有这种特性，默认不会自动更新。

7. 带有微秒精度的时间类型#

自 MySQL 5.6.4 版本起，TIME、DATETIME 和 TIMESTAMP 类型可以包含微秒部分，格式为 YYYY-MM-DD HH:MM:SS[.fraction]，其中 [.fraction] 是可选的小数部分，最多支持 6 位小数。

  • 示例：
    CREATE TABLE measurements (
    id INT AUTO_INCREMENT PRIMARY KEY,
    measurement_time DATETIME(6)
);

总结#

选择合适的时间数据类型取决于你的具体需求。如果你需要存储完整的日期和时间信息，DATETIME 和 TIMESTAMP 是最常见的选择。如果你只需要存储日期或时间的一部分，可以选择 DATE 或 TIME。对于需要高精度的时间记录，可以使用带有微秒精度的时间类型。

如果有任何其他问题或需要进一步的帮助，请告诉我！

时间使用建议#

我们平时开发中不可避免的就是要存储时间，比如我们要记录操作表中这条记录的时间、记录转账的交易时间、记录出发时间、用户下单时间等等。你会发现时间这个东西与我们开发的联系还是非常紧密的，用的好与不好会给我们的业务甚至功能带来很大的影响。所以，我们有必要重新出发，好好认识一下这个东西。

不要用字符串存储日期#

和绝大部分对数据库不太了解的新手一样，我在大学的时候就这样干过，甚至认为这样是一个不错的表示日期的方法。毕竟简单直白，容易上手。

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

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

Datetime 和 Timestamp 之间的抉择#

Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的数据类型，可以精确到秒。他们两者究竟该如何选择呢？

下面我们来简单对比一下二者。

时区信息#

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';

占用空间#

下图是 MySQL 日期类型所占的存储空间（官方文档传送门：https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html）：

img

在 MySQL 5.6.4 之前，DateTime 和 Timestamp 的存储空间是固定的，分别为 8 字节和 4 字节。但是从 MySQL 5.6.4 开始，它们的存储空间会根据毫秒精度的不同而变化，DateTime 的范围是 58 字节，Timestamp 的范围是 47 字节。

表示范围#

Timestamp 表示的时间范围更小，只能到 2038 年：

  • DateTime：1000-01-01 00:00:00.000000 ~ 9999-12-31 23:59:59.499999
  • Timestamp：1970-01-01 00:00:01.000000 ~ 2038-01-19 03:14:07.499999

性能#

由于 TIMESTAMP 需要根据时区进行转换，所以从毫秒数转换到 TIMESTAMP 时，不仅要调用一个简单的函数，还要调用操作系统底层的系统函数。这个系统函数为了保证操作系统时区的一致性，需要进行加锁操作，这就降低了效率。

DATETIME 不涉及时区转换，所以不会有这个问题。

为了避免 TIMESTAMP 的时区转换问题，建议使用指定的时区，而不是依赖于操作系统时区。

数值时间戳是更好的选择吗？#

很多时候，我们也会使用 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，原因是数值表示时间不够直观。下面是原文：

img

每种方式都有各自的优势，根据实际场景选择最合适的才是王道。下面再对这三种方式做一个简单的对比，以供大家实际开发中选择正确的存放时间的数据类型：

类型 存储空间 日期格式 日期范围 是否带时区信息
DATETIME 5~8 字节 YYYY-MM-DD hh:mm:ss[.fraction] 1000-01-01 00:00:00[.000000] ～ 9999-12-31 23:59:59[.999999] 否
TIMESTAMP 4~7 字节 YYYY-MM-DD hh:mm:ss[.fraction] 1970-01-01 00:00:01[.000000] ～ 2038-01-19 03:14:07[.999999] 是
数值型时间戳 4 字节 全数字如 1578707612 1970-01-01 00:00:01 之后的时间 否

作者：Esofar

出处：https://www.cnblogs.com/firsthelloworld/p/18602110

版权：本作品采用「署名-非商业性使用-相同方式共享 4.0 国际」许可协议进行许可。

posted @   我不想学编丿程  阅读(18)  评论(0)  编辑  收藏  举报
相关博文：
· Mysql_base
· Redis
· mysql数据库时间类型数据存储建议
· MySQL数据库时间类型数据存储建议
· MySQL日期类型选择建议
阅读排行：
· 被坑几百块钱后，我竟然真的恢复了删除的微信聊天记录！
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 没有Manus邀请码？试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· 无需6万激活码！GitHub神秘组织3小时极速复刻Manus，手把手教你使用OpenManus搭建本
more_horiz
keyboard_arrow_up light_mode palette
选择主题
menu
点击右上角即可分享
微信分享提示