mysql怎么调时区 mysql调整时区

mysql数据库时间怎么修改成东京时间

东京的时区是东九区，比我们北京东八区多1个时区，所以+9就是东京时间了

那我们怎么修改，有两种方法，一种是临时的，一种是长久的。

一：通过sql命令临时修改

# 设置全局时区 mysql set global time_zone = '+8:00';

Query OK, 0 rows affected (0.00 sec)

# 设置时区为东八区 mysql set time_zone = '+8:00';

Query OK, 0 rows affected (0.00 sec)

# 刷新权限使设置立即生效 mysql flush privileges;

Query OK, 0 rows affected (0.00 sec)

mysql show variables like '%time_zone%';

+------------------+--------+

| Variable_name | Value |

+------------------+--------+

| system_time_zone | EST |

| time_zone | +08:00 |

+------------------+--------+

2 rows in set (0.00 sec)

二：修改my.cnf实现永久修改

vi /etc/mysql/my.cnf

然后在mysqld下边的配置中添加一行：

default-time_zone = '+8:00'

然后重启mysql

service mysql restart

相关问答

Q1: mysql docker 怎么修改时区

1、查看当前时区

date -R

1

1

2、修改设置时区。先输入 tzselect 命令，然后根据提示，通过输入选项前面的数字来确定选项。我的例子，先选择 Asia ，再选择 Hong Kong。香港和中国采用了同样的东八区时间。

3、复制相应的时区文件，替换原来的时区文件。命令如下：

/usr/share/zoneinfo/Asia# cp Hong_Kong /etc/localtime

1

1

我们需要的时区文件在目录 /usr/share/zoneinfo/Asia 下。文件名字是 Hong_Kong。把它拷贝覆盖 /etc/localtime 文件。

4、重新输入命令 date -R，就可以看到修改时区后的中国时间了。

Q2: MySQL怎么设置时区为格林威治时间。

MySQL 时区默认是服务器的时区。

查看：

复制代码代码如下:

mysql SHOW VARIABLES LIKE '%time_zone%';

+------------------+--------+

| Variable_name| Value |

+------------------+--------+

| system_time_zone | CST|

| time_zone| SYSTEM |

+------------------+--------+

2 rows IN SET (0.00 sec)

可以通过修改my.cnf, 在 [mysqld] 之下加来修改时区。

default-time-zone=timezone

例如：

default-time-zone='+8:00'

修改后记得重启msyql。

注意一定要在 [mysqld] 之下加 ，否则会出现错误: unknown variable ‘default-time-zone=+8:00′

另外也可以通过命令：

SET time_zone=timezone

例如：比如北京时间（GMT+0800）

SET time_zone='+8:00'

这个和php的时区设置又有点差别，比如北京时间在php中是：

date_default_timezone_set('Etc/GMT-8');

美国pst时间（GMT-08:00）

SET time_zone = '-8:00';

复制代码代码如下:

mysql SET time_zone = '+8:00';

Query OK, 0 rows affected (0.00 sec)

mysql SELECT now();

+---------------------+

| now() |

+---------------------+

| 2008-12-29 11:26:36 |

+---------------------+

1 row IN SET (0.00 sec)

mysql SET time_zone = '-8:00';

Query OK, 0 rows affected (0.00 sec)

mysql SELECT now();

+---------------------+

| now() |

+---------------------+

| 2008-12-28 19:27:09 |

+---------------------+

1 row IN SET (0.00 sec)

Q3: mysql修改和查看时区（十五）

1. 查看时区命令

2. GMT、UTC、DST、CST时区代表的意义

2.1 GMT：Greenwich Mean Time 

2.2 UTC: Coordinated Universal Time

2.3 DST: Daylight Saving Time

2.4 CST:Central Standard Time

3.  修改时区

3.1 仅修改当前会话的时区，停止会话失效(CET)

3.2 修改全局的时区配置

Q4: docker中MySQL的时区修改

docker中的mysql时区是使用了世界标准时间(UTC)，把时区改成东八区方法：

1、启动容器时设置： 添加如下配置：

2、进入docker配置：(重启才能生效--永久生效)

3、临时修改（从mysql上修改，重启失效）

Q5: MySQL:一文弄懂时区&time_zone

你还在被以下问题困扰吗：

MySQL的安装规范中应该设置什么时区？

JAVA应用读取到的时间和北京时间差了14个小时，为什么？怎么解决？

已经运行一段时间的业务，修改MySQL的时区会影响已经存储的时间类型数据吗？

迁移数据时会有导致时间类型数据时区错误的可能吗？

...

看完这篇文章，你能解决上面所有的疑惑。首先出场的是和时区相关的启动参数和系统变量。

如果要在 MySQL 启动时就指定时区，则应该使用启动参数： default-time-zone ，示例：

启动后我们可以看到控制时区的系统变量，其中 time_zone 变量控制时区，在MySQL运行时可以通过 set 命令修改（注意：不可以写在 my.cnf 中）：

启动参数和系统变量的可用值遵循相同的格式：

system_time_zone 变量只有全局值没有会话值，不能动态修改，MySQL 启动时，将尝试自动确定服务器的时区，并使用它来设置 system_time_zone 系统变量， 此后该值不变。当 time_zone='system' 时，就是使用的这个时区，示例中 time_zone 就是 CST，而 CST 在 RedHat 上就是东八区：

概括一下就两点：

不仅是select now()，包括insert .. values(now())、以及字段的 DEFAULT CURRENT_TIMESTAMP 属性也受此影响：

timestamp 数据类型会存储当时session的时区信息，读取时会根据当前 session 的时区进行转换；而 datetime 数据类型插入的是什么值，再读取就是什么值，不受时区影响。也可以理解为已经存储的数据是不会变的，只是 timestamp 类型数据在读取时会根据时区转换：

关于时区所有明面上的东西都在上面了，我们前面提到的困扰就是在暗处的经验。

1. MySQL的安装规范中应该设置什么时区？

对于国内的业务了，在 my.cnf 写入 default-time-zone='+08:00' ，其他地区和开发确认取对应时区即可。

为什么不设置为 system 呢？使用系统时间看起来也是个不错的选择，比较省事。不建议的原因有两点：

2. JAVA应用读取到的时间和北京时间差了14个小时，为什么？怎么解决？

这通常是 JDBC 参数中没有为连接设置时区属性（用 serverTimezone 参数指定），并且MySQL中没有设置全局时区，这样MySQL默认使用的是系统时区，即 CST。这样一来应用与MySQL 建立的连接的 session time_zone 为 CST ，前面我们提到 CST 在 RedHat 上是 +08:00 时区，但其实它一共能代表4个时区：

JDBC在解析CST时使用了美国标准时间，这就会导致时区错误。要解决也简单：一是遵守上面刚说到的规范，对MySQL显式地设置'+08:00'时区；二是JDBC设置正确的 serverTimezone。

3. 已经运行一段时间的业务，修改MySQL的时区会影响已经存储的时间类型数据吗？

完全不会，只会影响对 timestamp 数据类型的读取。这里不得不提一句，为啥要用 timestamp？用 datetime 不香吗，范围更大，存储空间其实差别很小，赶紧加到开发规范中吧。

4. 迁移数据时会有导致时间类型数据时区错误的可能吗？

这个还真有。

如何避免？mysqldump 也提供了一个参数 --skip-tz-utc ，意思就是导出数据的那个连接不设置 UTC 时区，使用 MySQL 的 global time_zone 系统变量值。

其实 mysqldump 导出 sql 文件时默认也是使用 UTC 时区，并且会在导出的 sql 文件头部带有 session time_zone 信息，这样可以保证导 SQL 文件导入和导出时使用相同的时区，从而保证数据的时区正确（而导出的 csv 文件显然不可以携带此信息）。需要注意的是 --compact 参数会去掉 sql 文件的所有头信息，所以一定要记得： --compact 参数得和 --skip-tz-utc 一起使用。