文章目录
- 前言
- 1. 时区参数影响
- 2. 如何设置
- 3. 字段类型选择
前言
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 已经离现在不远了,是需要重视的,业务又将面临一次类似千年虫的问题。