mysql now()函数调用系统时间不对的解决方法

目录

• 向数据库写记录最好用不用客户端时间
• mysql服务器时区不等于东八区的问题
• MySQL时区的设置和docker有关

今天在MySQL的Now函数上踩了两个坑，花了不少时间。

向数据库写记录最好用不用客户端时间

第一js个坑是客户端、服务器的系统时间不一致。

在执行依赖时间的SQL查询的时候，使用了客户端本地的时间格式，客户端程序返回当前时间是：‘7/18/2022 10:02:43’，然而MYSQL就不能正确android识别了，也没有报错，导致这个这个错误隐藏了很久才被发现。

实际上，如果给出的时间格式是这样：‘2022/7/18 10:02:43’，就会返回预期的结果。猜想这次运行客户端程序的服务器虽然也是中文版，但是内核应该是英文编程客栈版的，因此系统默认的时间格式和我们常见的不同，于是MySQL把它认作是。。。（一个古怪的时间去了）

解决办法

尽可能不使用客户端的时间，不准确还有时区问题，用MySQL服务器端时间Now()来进行查询和保存记录。

MySQL服务器时区不等于东八区的问题

这次遇到的MySQL的版本默认的时区是UTC，也就是标准时间。如果数据记录的时间是北京时间，也就是东八区的时间，那么MySQL的Now函数返回的时间和数据记录的时间相差了八个小时。

查询MySQL时区：

mysql> show variables like "%time_zone%";
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | UTC    |
| time_zone        | SYSTEM |
+------------------+--------+

设置MySQL时间为北京时间

mysql> set global time_zone = '+8:00';
Query OK, 0 rows affected
mysql> set time_zone = '+8:00';
Query OK, 0 rows affected
mysql> flush privileges;
Query OK, 0 rows affected

再查询下MySQL时区，验证下Now返回了北京时间

mysql> show variables like "%time_zone%";
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | UTC    |
| time_zone        | +08:00 |
+------------------+--------+
mysql&编程客栈gt; SELECT NOW();
+---------------------+
| NOW()               |
+---------------------+
| 2022-07-19 18:57:35 |
+---------------------+
1 row in set

MySQL时区的设置和Docker有关

这里说下花了我大量时间的坑，也就是这个服务器的MySQL是通过Docker安装的，我就懒得去修改MySQL的配置文件了，而配置文件里没有配置默认时区。

理论上，MySQL就会应用本地服务器的时区，而本地服务器的时区已经设置成东八区了，在系统控制台我能看到返回的当前时间是北京时间了。

问题就在于上面这个“理论”不靠谱，不是的，MySQL依然是返回UTC时间。

我记忆的这个“理论”应该是有问题的，但没有搞清楚具体问题是什么，怀疑是和Dockers有关，如果是直接安装的MySQL在不配置默认时区时似乎没有遇到这个问题。

解决办法：

结论是不管如何，还是手动在设置下系统的时区吧！或者在写MySQL的配置文件时，增加如下一个配置，然后才能使用Now()函数。

修改my.cnf文件，加入如下1行：

default-time-zone='+08:00' # 数据表默认时区

如果是中途 修改，需要重启Docker，不能偷懒。

到此这篇关于MySQL now函数使用的坑的文章就介绍到这了,更多相关MySQL now内容请搜索我编程客栈们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！