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

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

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

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

实际上，如果给出的时间格式是这样：‘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> 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，不能偷懒。