189 8069 5689
1。在mysql的命令模式下使用
创新互联是由多位在大型网络公司、广告设计公司的优秀设计人员和策划人员组成的一个具有丰富经验的团队，其中包括网站策划、网页美工、网站程序员、网页设计师、平面广告设计师、网络营销人员及形象策划。承接：成都网站制作、网站设计、外贸网站建设、网站改版、网页设计制作、网站建设与维护、网络推广、数据库开发,以高性价比制作企业网站、行业门户平台等全方位的服务。
mysql
select
CURTIME();
或
mysql
select
now();
看当前时间是否正确，可以看到mysql当前使用的是那一个时区的时间。
2。在mysql命令行中更改时区
mysql
SET
time_zone
=
'+8:00';
#
此为北京时，我们所在东8区
mysql
flush
privileges;
#
立即生效
此时mysql时区已更改正确，与系统时区都使用为
Shanghai时间了。
####
这种方法好像只能在终端上使用，退出终端后时间又会变成原来的，看来只能重启mysql了。
3。重启mysql也应没有问题，此时mysql会主动读取系统时间。
方法二：
如果mysql数据库可以重启，直接重启，mysql应可以立即主动读取系统时间，如果不行则更改mysql的配置文件(mysql.cnf)
在my.cnf的
[mysqld]区域中加上
default-time_zone
=
'+8:00'
#此为北京时。
补充：
如果想临时解决时间显示问题，可以用php或其他语言动态修改下mysql的时区。
具体方法：
在mysql_connect()下使用mysql_query("SET
time_zone
=
'+8:00'")。
这样可以在保证你不重启的情况下改变时区。但是mysql的某些系统函数还是不能用如：now（）。
MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客户端中用来设置读取超时时间的参数。在 MySQL 的官方文档中，该参数的描述是这样的：
MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.
也就是说在需要的时候，实际的超时时间会是设定值的 3 倍。但是实际测试后发现实际的超时时间和设置的超时时间一致。
而具体什么时候发生三倍超时，在文档中没有找到。所以对 MySQL 5.7.20 的源码进行了一些分析。
使用 GDB 调试代码找了实际与 mysql server 通信的代码，如下：
请点击输入图片描述
其中 vio_read() 函数中，使用 recv 和 poll 来读取报文和做读取超时。net_should_retry() 函数只有在发生 EINTR 时才会返回 true。从这段代码来看是符合测试结果的，并没有对读取进行三次重试。只有在读取操作被系统中断打断时才会重试，但是这个重试并没有次数限制。
从上面代码的分析可以看出，代码的逻辑和文档的描述不符。于是在一顿搜索后，找到了一个 MySQL 的 BUG(Bug #31163)。该 BUG 报告了在 MySQL 5.0 中，MySQL c api 读取的实际超时时间是设置的三倍，与现有文档描述相符。于是对 MySQL 5.0.96 的代码又进行分析。
同样使用 GDB 找到了通信部分的代码。这次找到了重试三次的代码，如下：
请点击输入图片描述
这个版本的 MySQL api 的读写超时是直接使用的 setsockopt 设置的。第一次循环，在 A 点发生了第一次超时（虽然注释写的非阻塞，但是客户端的连接始终是阻塞模式的）。然后在 B 点将该 socket 设置为阻塞模式，C 点这里重置 retry 次数。由于设置了 alarm 第二次以后的循环会直接进入 D 点的这个分支，并且判断循环次数。作为客户端时net-retry_count 始终是 1，所以重试了两次，共计进行了 3 次 vioread 后从 E 点退出函数。
由上面的分析可知，MySQL 文档对于该参数的描述已经过时，现在的 MYSQL_OPT_READ_TIMEOUT 并不会出现三倍超时的问题。而 Bug #31163 中的处理结果也是将文档中该参数的描述更新为实际读取超时时间是设定时间的三倍。也许是 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
怎样修改mysql中的时间和日期？
建议你安装PHPMYADMIN或者MYSQL-FRONT这类软件，用它们来修改就比较简单。
另外一个办法，在留言前修改服务器的系统时间，这样保存的留言就是以前的。
具体操作步骤如下：
1、第一步，打开sql数据库，新建一个表。格式原因，以下的date＿time和time＿time为日期类型，如图所示。
2、第二步，若是简单的查询表，那么就会以日期格式显示出来，如图所示。
3、第三步，使用函数to＿char，把查询日期显示结果更改成日期形式，获得以下结果，如图所示。
4、第四步，点击查询编辑器选项，键入以下代码，如图所示。
5、第五步，可以看到日期就修改好了，如图所示。
docker中的mysql时区是使用了世界标准时间(UTC)，把时区改成东八区方法：
1、启动容器时设置： 添加如下配置：
2、进入docker配置：(重启才能生效--永久生效)
3、临时修改（从mysql上修改，重启失效）