论述营销型网站的评价标准,建立网络的流程,如何编辑网页,如何做平台推广赚钱你还在被以下问题困扰吗#xff1a; MySQL 的安装规范中应该设置什么时区#xff1f; JAVA 应用读取到的时间和北京时间差了 14 个小时#xff0c;为什么#xff1f;怎么解决#xff1f; 已经运行一段时间的业务#xff0c;修改 MySQL 的时区会影响已经存储的时间类型数据…你还在被以下问题困扰吗 MySQL 的安装规范中应该设置什么时区 JAVA 应用读取到的时间和北京时间差了 14 个小时为什么怎么解决 已经运行一段时间的业务修改 MySQL 的时区会影响已经存储的时间类型数据吗 迁移数据时会有导致时间类型数据时区错误的可能吗 … 看完这篇文章你能解决上面所有的疑惑。
启动参数系统变量
如果要在 MySQL 启动时就指定时区则应该使用启动参数default-time-zone示例
##方法 1在启动命令中添加
mysqld --default-time-zone08:00 ##方法 2在配置文件中添加
[mysqld]
default-time-zone08:00启动后我们可以看到控制时区的系统变量其中 time_zone 变量控制时区在 MySQL 运行时可以通过 set命令修改注意不可以写在 my.cnf 中
#查看
mysql show global variables like %time%zone%;
--------------------------
| Variable_name | Value |
--------------------------
| system_time_zone | CST |
| time_zone | 08:00 |
--------------------------
2 rows in set (0.00 sec)#修改全局时区所有新创建的 session 都会被修改
set global time_zone00:00;#修改当前 session 的时区
set session time_zone00:00;启动参数和系统变量的可用值遵循相同的格式
SYSTEM 表明使用系统时间相对于 UTC 时间的偏移比如 08:00 或者 -6:00某个时区的名字比如 ‘Europe/Helsinki’‘‘Asia/Shanghai’’ 或 ‘UTC’前提是已经把时区信息导入到了 mysql 库否则会报错。导入方法mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -S /tmp/mysqld.sock mys
system_time_zone 变量只有全局值没有会话值不能动态修改MySQL 启动时将尝试自动确定服务器的时区并使用它来设置 system_time_zone 系统变量 此后该值不变。当 time_zonesystem 时就是使用的这个时区示例中 time_zone 就是
mysql show global variables like %time%zone%;
--------------------------
| Variable_name | Value |
--------------------------
| system_time_zone | CST |
| time_zone | SYSTEM |
--------------------------
2 rows in set (0.00 sec)#可以看到在当前操作系统上 CST 就是 08:00 时区
[rootlocalhost ~]# date -R
Mon, 30 Dec 2024 14:44:48 0800
[rootlocalhost ~]# date
2024年 12月 30日 星期一 14:44:56 CST时区影响了什么
概括一下就两点 1. NOW() 和 CURTIME() 系统函数的返回值受当前 session 的时区影响
不仅是 select now()包括 insert .. values(now())、以及字段的 DEFAULT CURRENT_TIMESTAMP 属性也受此影响
mysql set time_zone00:00;
Query OK, 0 rows affected (0.00 sec)mysql select now(),CURTIME();
--------------------------------
| now() | CURTIME() |
--------------------------------
| 2024-12-30 06:53:42 | 06:53:42 |
--------------------------------
1 row in set (0.00 sec)mysql set time_zone08:00;
Query OK, 0 rows affected (0.00 sec)mysql select now(),CURTIME();
--------------------------------
| now() | CURTIME() |
--------------------------------
| 2024-12-30 14:53:59 | 14:53:59 |
--------------------------------
1 row in set (0.00 sec)2. timestamp 数据类型字段存储的数据受时区影响
timestamp 数据类型会存储当时 session 的时区信息读取时会根据当前 session 的时区进行转换而datetime 数据类型插入的是什么值再读取就是什么值不受时区影响。也可以理解为已经存储的数据是不会变的只是 timestamp 类型数据在读取时会根据时区转换
mysql set time_zone08:00;
Query OK, 0 rows affected (0.00 sec)mysql create table c(ts timestamp, dt datetime);
Query OK, 0 rows affected (0.02 sec)mysql insert into c values(2024-12-30 14:59:39,2024-12-30 14:58:39);
Query OK, 1 row affected (0.00 sec)mysql select * from c;
------------------------------------------
| ts | dt |
------------------------------------------
| 2024-12-30 14:59:39 | 2024-12-30 14:58:39 |
------------------------------------------
1 row in set (0.00 sec)mysql set time_zone00:00;
Query OK, 0 rows affected (0.00 sec)mysql select * from c;
------------------------------------------
| ts | dt |
------------------------------------------
| 2024-12-30 06:59:39 | 2024-12-30 14:58:39 |
------------------------------------------
1 row in set (0.00 sec)结论
关于时区所有明面上的东西都在上面了下面来是几个常见的问题。 1. MySQL 的安装规范中应该设置什么时区
对于国内的业务了在 my.cnf 写入 default-time-zone‘08:00’ 其他地区和开发确认取对应时区即可。
为什么不设置为 system 呢使用系统时间看起来也是个不错的选择比较省事。不建议的原因有两点
操作系统的设置可能不归 DBA 管万一别人没有设置正确的系统时区呢只做自己有把握的事更稳妥多了一层系统调用性能有损耗。
2. JAVA 应用读取到的时间和北京时间差了 14 个小时为什么怎么解决
这通常是 JDBC 参数中没有为连接设置时区属性用 serverTimezone 参数指定并且 MySQL 中没有设置全局时区这样 MySQL 默认使用的是系统时区即 CST。这样一来应用与 MySQL 建立的连接的session time_zone 为 CST前面我们提到 CST 在 RedHat 上是 08:00 时区但其实它一共能代表 4 个时区
Central Standard Time (USA) UT-6:00 美国标准时间Central Standard Time (Australia) UT9:30 澳大利亚标准时间China Standard Time UT8:00 中国标准时间Cuba Standard Time UT-4:00 古巴标准时间
JDBC 在解析 CST 时使用了美国标准时间这就会导致时区错误。要解决也简单一是遵守上面刚说到的规范对 MySQL 显示地设置’08:00’时区二是 JDBC 设置正确的 serverTimezone 。
3. 已经运行一段时间的业务修改 MySQL 的时区会影响已经存储的时间类型数据吗
完全不会只会影响对 timestamp 数据类型的读取。这里不得不提一句为啥要用 timestamp用 datetime 不香吗范围更大存储空间其实差别很小赶紧加到开发规范中吧。
4. 迁移数据时会有导致时间类型数据时区错误的可能吗 这个还真有还是针对 timestamp 数据类型比如使用 mysqldump 导出 csv 格式的数据默认这种导出方式会使用 UTC 时区读取 timestamp 类型数据这意味导入时必须手工设置 session.time_zone00:00’才能保证时间准确
# test.t 导出成 csv
mysqldump -S /data/mysql/data/3306/mysqld.sock --single-transaction \
--master-data2 -t -T /data/backup/test3 --fields-terminated-by, test t#查看导出数据
cat /data/backup/test3/t.txt
2024-12-30 06:59:39 2024-12-30 14:58:39如何避免mysqldump 也提供了一个参数 --skip-tz-utc意思就是导出数据的那个连接不设置 UTC 时区使用 MySQL 的 global time_zone 系统变量值
其实 mysqldump 导出 sql 文件时默认也是使用 UTC 时区并且会在导出的 sql 文件头部带有 session time_zone 信息这样可以保证导 SQL 文件导入和导出时使用相同的时区从而保证数据的时区正确 而导出的 csv 文件显然不可以携带此信息。需要注意的是 --compact 参数会去掉 sql 文件的所有头信息所以一定要记得--compact 参数得和 --skip-tz-utc 一起使用
以上就是全部内容了如果对大家有帮助请点个赞创作不易谢谢
