国外营销型网站,怎样做网站的优化工作,海南快速seo排名优化,用flash制作网站文章目录 前言1. 时区参数影响2. 如何设置3. 字段类型选择 前言
MySQL 时区参数 time_zone 有什么用#xff1f;修改它有什么影响#xff1f;如何设置该参数#xff0c;本篇文章会详细介绍。
1. 时区参数影响
time_zone 参数影响着 MySQL 系统函数还有字段的 DEFAULT CUR… 文章目录 前言1. 时区参数影响2. 如何设置3. 字段类型选择 前言
MySQL 时区参数 time_zone 有什么用修改它有什么影响如何设置该参数本篇文章会详细介绍。
1. 时区参数影响
time_zone 参数影响着 MySQL 系统函数还有字段的 DEFAULT CURRENT_TIMESTAMP 的属性。
查询当前的时区8:00 就代表国内的时区
rootmysql 15:08: [(none)]select time_zone;
-------------
| time_zone |
-------------
| 08:00 |
-------------查询当前时间
rootmysql 15:09: [(none)]select now();
---------------------
| now() |
---------------------
| 2024-12-12 15:09:44 |
---------------------修改时区为 UTC -8:00 美国时间
rootmysql 15:09: [(none)]set global time_zone -08:00;
Query OK, 0 rows affected (0.00 sec)查询当前时间
rootmysql 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)
) ENGINEInnoDB AUTO_INCREMENT14 DEFAULT CHARSETutf8;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)
) ENGINEInnoDB AUTO_INCREMENT14 DEFAULT CHARSETutf8;模拟数据插入
insert into api_timestamp(user, enabled) values (08:00, b1);
insert into api_datetime(user, enabled) values (08:00, b1);查询表数据
rootmysql 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)rootmysql 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, b1);
insert into api_datetime(user, enabled) values (-08:00, b1);rootmysql 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)rootmysql 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-zone08: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 已经离现在不远了是需要重视的业务又将面临一次类似千年虫的问题。
