MySQL驱动中关于时间的坑

发布网友 发布时间：2024-10-22 16:58

我来回答

共1个回答

热心网友 时间：5分钟前

背景：MySQL 8.0数据库；

最近在开发一个小型框架时，由于框架本身较为简洁，我选择直接使用JDBC来操作数据库。在处理一个datetime类型的字段时，遇到了一个有趣的问题。

我在Java代码中使用java.time.LocalDateTime来处理这个日期字段。为了确认java.sql.PreparedStatement.setObject(int, java.lang.Object)方法是否可以正确处理java.time.LocalDateTime类型的入参，我编写了一小段测试用例。在执行JDBC调用设置参数时，一切看似正常，但当我查看数据库中的数据时，发现日期竟然少了14个小时，这让我感到困惑。

经过分析，我意识到这是时区问题。由于我们位于东8区，比UTC时间快8小时，因此存储到数据库后的时间比我们现在的实际时间慢了14个小时，即比UTC时间慢了6个小时，这正是CST时区。这让我怀疑我的服务器是否被搬到了北美，但事实并非如此。

经过检查，我发现MySQL的默认时区设置为CST，与我服务器的时区设置不一致。修改MySQL的默认时区为UTC+8后，问题得到了解决。

然而，我注意到使用mybatis的项目没有遇到这个问题，这让我产生了疑问。经过分析，我发现这是由于两个项目使用的MySQL驱动版本不同导致的。使用mybatis的项目使用的MySQL驱动版本是8.0.26，而直接使用JDBC的项目使用的版本是8.0.11。在8.0.26版本的驱动中，日期处理没有使用MySQL服务端的时区，因此存储到数据库中的日期是正确的。而8.0.11版本的驱动则使用了MySQL服务端的时区，导致了日期的变化。

为了解决这个问题，我采用了升级MySQL驱动到8.0.26版本的方案，或者修改数据库默认时区。最后，我选择了升级驱动的方法。

在此，我建议大家在升级jar包时要谨慎，尤其是涉及底层驱动的jar包，以防止出现兼容性问题。