MySQL Connect/J 8.0时区陷阱

最近公司正在升级Spring Boot版本（从1.5升级到2.1），其间踩到一个很是隐晦的MySQL时区陷阱，具体来讲，就是数据库读出的历史数据的时间和实际时间差了14个小时，而新写入的数据又都正常。若是你以前也是使用默认的MySQL时区配置，那么大几率会碰到这个问题，深究其背后的缘由又涉及到不少技术细节，故整理出来分享给你们。

首先来看一下缘由。升级到Boot 2.1以后，MySQL Connect/J版本也随之升级到8.0，会优先使用链接参数（serverTimezone）中指定的时区，若是没有指定，则再使用数据库配置的时区，参考下面的官宣（对应的源代码是com.mysql.cj.protocol.a.NativeProtocol#configureTimezone()）。因为咱们以前数据库链接参数没有指定时区，而且数据库配置的是默认的CST时区（美国中部时区，即-6:00），因此读取出来的时间出现误差。

Connector/J 8.0 always performs time offset adjustments on date-time values, and the adjustments require one of the following to be true:

• The MySQL server is configured with a canonical time zone that is recognizable by Java (for example, Europe/Paris, Etc/GMT-5, UTC, etc.)
• The server's time zone is overridden by setting the Connector/J connection property serverTimezone (for example, serverTimezone=Europe/Paris).

找到缘由以后，解决办法就比较直白了，

方法一：数据库的链接参数添加serverTimezone=Asia/Shanghai或者serverTimezone=GMT%2B8。Boot 1.5下不须要添加此参数，但添加了也无妨。

方法二：修改MySQL数据库的time_zone配置，改成+8:00（默认是SYSTEM）。采用此方法，则不须要修改数据库链接参数。

方法二显然更优，一次修改，终生受益。但要注意，对于升级到Boot 2.1以后新生成的那批数据，若是包含时间类型的字段而且该字段值是应用指定的而不是数据库生成的（例如DEFAULT CURRENT_TIMESTAMP），那么须要手动修复（加上误差的小时数）。

两个解决办法都很简单，有同窗立刻会问，为何Boot 1.5下没有这个问题？为何Boot 2.0下读取历史数据存在14个小时的误差，而新生成的数据又是好的？要回答这两个问题，看官宣就不够了，须要读一下MySQL Connect/J的源代码。

谜题一，为何Boot 1.5下没有这个问题？答案隐藏在com.mysql.jdbc.ResultSetImpl和com.mysql.jdbc.ConnectionImpl两个类的源代码中。

// 源代码：com.mysql.jdbc.ResultSetImpl
private TimeZone getDefaultTimeZone() {
        // useLegacyDatetimeCode默认为true，所以使用connection的默认时区
        return this.useLegacyDatetimeCode ? this.connection.getDefaultTimeZone() : this.serverTimeZoneTz;
    }

// 源代码：com.mysql.jdbc.ConnectionImpl
public ConnectionImpl(String hostToConnectTo, int portToConnectTo, Properties info, String databaseToConnectTo, String url) throws SQLException {
        // connection的默认时区使用的是JVM的默认时区，通常为操做系统的时区
        // We store this per-connection, due to static synchronization issues in Java's built-in TimeZone class...
        this.defaultTimeZone = TimeUtil.getDefaultTimeZone(getCacheDefaultTimezone());
}

Boot 1.5下，MySQL Connect/J默认使用操做系统的时区（Asia/Shanghai，即+8:00），而忽略链接参数或者数据库指定的时区，所以无论是读数据仍是写数据都是使用统一的时区，所以不存在时间误差。

谜题二，为何Boot 2.0下读取历史数据存在14个小时的误差，而新生成的数据又是好的？升级到Boot 2.0以后，MySQL Connect/J改成使用数据库配置的CST时区，而历史数据是在Boot 1.5下的Asia/Shanghai时区生成的，所以读出来存在14（-6:00和+8:00之间）个小时的误差。对于新生成的数据，因为同处在CST时区下，所以没有误差。

解完这两个谜题，你可能还有些疑惑。那么接下来，结合数据流转的顺序，咱们再来分析一下数据流转过程当中时区的变化。

设定Application-1为数据生产方，Application-2为数据消费方，TZ-IN1为Application-1所处的时区，TZ-IN2为Application-1写入数据库的时区，TZ-OUT1为Application-2读出数据库的时区，TZ-OUT2为Application-2所处的时区。如前所述，TZ-IN2和TZ-OUT1由链接参数或者数据库配置决定。

整个数据流转过程，会涉及3次显式的时区转换和1次隐式的时区转换。

• 转换①（显式）：TZ-IN1转TZ-IN2，这个转换由MySQL Connect/J完成（参考com.mysql.cj.ClientPreparedQueryBindings#setTimestamp()，限于篇幅，此处再也不展开分析）。
• 转换②（隐式）：TZ-IN2转无时区，MySQL内部存储时间类型的字段时或者忽略时区（DateTime类型）或者使用UTC（Timestamp类型），参考MySQL官宣的时间类型部分。
• 转换③（显式）：无时区转TZ-OUT1，将MySQL读出的无时区时间置为TZ-OUT1时区（参考com.mysql.cj.result.SqlTimestampValueFactory#localCreateFromTimestamp()）。
• 转换④（显式）：TZ-OUT1转TZ-OUT2，这个转换由Application-2负责，通常在DAO层完成。

仔细分析这4次时区转换，其中①、②、③都是由MySQL完成，正确性不用怀疑，但因为TZ-IN2和TZ-OUT1都是由应用指定，若是二者值不相同，那么最后结果就会出现误差（咱们踩到的就是这个坑）。至于④，那么就得靠应用来保证正确性了，通常也不会出错。说句题外话，无论是时区转换，仍是其余类型的数据转换（好比字符集转换），咱们能够发现，正确转换的关键在于数据接收方必须使用和数据发送方相同的格式。这看上去像是一句废话，倒是解决此类问题的底层心法。

至此，这个MySQL Connect/J 8.0的时区陷阱就算被填平了，但愿你从中有所收获。