MySQL 时区参数 time_zone 详解

前言

MySQL 时区参数 time_zone 有什么用？修改它有什么影响？如何设置该参数，本篇文章会详细介绍。

1. 时区参数影响

time_zone 参数影响着 MySQL 系统函数还有字段的 DEFAULT CURRENT_TIMESTAMP 的属性。

查询当前的时区，+8:00 就代表国内的时区：

root@mysql 15:08:  [(none)]>select @@time_zone;
+-------------+
| @@time_zone |
+-------------+
| +08:00      |
+-------------+

查询当前时间：

root@mysql 15:09:  [(none)]>select now();
+---------------------+
| now()               |
+---------------------+
| 2024-12-12 15:09:44 |
+---------------------+

修改时区，为 UTC -8:00 美国时间：

root@mysql 15:09:  [(none)]>set global time_zone = '-08:00';
Query OK, 0 rows affected (0.00 sec)

查询当前时间：

root@mysql 15:09:  [(none)]>select now();
+---------------------+
| now()               |
+---------------------+
| 2024-12-11 23:09:55 |
+---------------------+

另外，需要注意的是 timestamp 类型，会随着 time_zone 的值产生变化，而 datetime 类型则不会，请看下方演示。

确认当前 time_zone 参数值：

select @@time_zone;+-------------+
| @@time_zone |
+-------------+
| +08:00      |
+-------------+

创建测试表结构，两张表的区别是 created_at、updated_at 分别为 datetime 和 timestamp 类型。

CREATE TABLE `api_datetime` (`id` bigint(64) NOT NULL AUTO_INCREMENT,user varchar(10),`created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',`updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',`enabled` bit(1) NOT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8;CREATE TABLE `api_timestamp` (`id` bigint(64) NOT NULL AUTO_INCREMENT,user varchar(10),`created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',`updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',`enabled` bit(1) NOT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8;

模拟数据插入：

insert into api_timestamp(user, enabled) values ('+08:00', b'1');
insert into api_datetime(user, enabled) values ('+08:00', b'1');

查询表数据：

root@mysql 16:21:  [test]>select user,created_at, updated_at from api_datetime;
+--------+---------------------+---------------------+
| user   | created_at          | updated_at          |
+--------+---------------------+---------------------+
| +08:00 | 2024-12-12 16:20:34 | 2024-12-12 16:20:34 |
+--------+---------------------+---------------------+
1 row in set (0.00 sec)root@mysql 16:21:  [test]>select user,created_at, updated_at from api_timestamp;
+--------+---------------------+---------------------+
| user   | created_at          | updated_at          |
+--------+---------------------+---------------------+
| +08:00 | 2024-12-12 16:20:33 | 2024-12-12 16:20:33 |
+--------+---------------------+---------------------+

修改 time_zone 参数值，为 -8:00：

set global time_zone = '-8:00';

插入测试数据：

insert into api_timestamp(user, enabled) values ('-08:00', b'1');
insert into api_datetime(user, enabled) values ('-08:00', b'1');

root@mysql 16:25:  [test]>select user,created_at, updated_at from api_datetime;
+--------+---------------------+---------------------+
| user   | created_at          | updated_at          |
+--------+---------------------+---------------------+
| +08:00 | 2024-12-12 16:20:34 | 2024-12-12 16:20:34 |
| -08:00 | 2024-12-12 00:25:52 | 2024-12-12 00:25:52 |
+--------+---------------------+---------------------+
2 rows in set (0.00 sec)root@mysql 16:25:  [test]>select user,created_at, updated_at from api_timestamp;
+--------+---------------------+---------------------+
| user   | created_at          | updated_at          |
+--------+---------------------+---------------------+
| +08:00 | 2024-12-12 00:20:33 | 2024-12-12 00:20:33 |
| -08:00 | 2024-12-12 00:25:52 | 2024-12-12 00:25:52 |
+--------+---------------------+---------------------+
2 rows in set (0.00 sec)

由上方测试，我们发现如果字段设置为 CURRENT_TIMESTAMP 无论是 datetime 还是 timestamp 类型，都会随 time_zone 参数影响，不过 datetime 类型的历史数据不会受影响，timestamp 类型的历史数据，会随着 time_zone 的调整而发生变化。

2. 如何设置

推荐直接写在 MySQL 的配置文件中，需要重启生效。

[mysqld]
default-time-zone='+08:00'

该参数默认为 SYSTEM 表示该参数值，取自操作系统的时区设置。不过还是建议在 MySQL 参数文件中设置一下，因为操作系统可能可能不完全归 DBA 管理，万一有人突然调整了，可能会引起线上问题。

另外，如果 time_zone 使用默认的 system 值，表示默认使用操作系统的时区，则每次通过时区计算时间时，要调用操作系统底层系统函数 __tz_convert()，而这个函数需要额外的加锁操作，以确保这时操作系统时区没有修改。高并发的时候会导致 TIMESTAMP 类型的表和操作，性能降低。

3. 字段类型选择

业务中尽量使用 datetime 类型来存储时间，除了历史数据不会随着时区发生变化外，还有一个最大值限制问题。

TIMESTAMP 存储的是 1970-01-01 00:00:00’ 到现在的毫秒数，TIMESTAMP 占用 4 个字节，因此其存储的时间上限只能到 2038-01-19 03:14:07 已经离现在不远了，是需要重视的，业务又将面临一次类似千年虫的问题。