JDBC驱动对时间戳的版本适配和中间件相关注意点

背景

业务在使用测试中，发现自己配置的MySQL表，某些时间字段的精度被截取了。因为使用了公司的中间层，怀疑是中间层导致的。同时经过对比，和业务正常使用的MySQL5.7是没有类似问题的。因此和业务进行了分析。

分析

首先，正如前面所描述，问题是MySQL表字段的时间精度在处理后降低了，某些小数秒的时间被截断了。经过分析得知是MySQL在5.6.4以后才支持了更高精度的时间表示。同样，在mysql-connector-java:5.1.23里，对这个进行了适配，如果获取的MySQL版本是5.6.4及以上的，则保持精度，否则截取精度。具体的实现是在com.mysql.jdbc.PreparedStatement#detectFractionalSecondsSupport，可以参考这个连接jdbc fractional seconds

    protected void detectFractionalSecondsSupport() throws SQLException {
        this.serverSupportsFracSecs = this.connection != null && this.connection.versionMeetsMinimum(5, 6, 4);
    }

所以，这里要支持小数秒，对应的MySQL服务版本要至少是5.6.4

解决

再回到业务提供的问题，经过排查，发现业务在进入我们的数据库中间件之后，获得的实际版本是5.5。而在我们的中间件执行select version()，获取到的是实际后端MySQL实例的版本号5.7.25-log。再观察后知道jdbc驱动中保存的版本是在建立连接，镜像账号握手阶段读取的，具体可以在抓包中查看到具体字段。实际的代码实现可以参考如下代码：

/**
     * Initialize communications with the MySQL server. Handles logging on, and
     * handling initial connection errors.
     *
     * @param user DOCUMENT ME!
     * @param password DOCUMENT ME!
     * @param database DOCUMENT ME!
     *
     * @throws SQLException DOCUMENT ME!
     * @throws CommunicationsException DOCUMENT ME!
     */
    void doHandshake(String user, String password, String database)
        throws SQLException {
        // Read the first packet
        this.checkPacketSequence = false;
        this.readPacketSequence = 0;

        Buffer buf = readPacket();

        // Get the protocol version
        this.protocolVersion = buf.readByte();

        if (this.protocolVersion == -1) {
            try {
                this.mysqlConnection.close();
            } catch (Exception e) {
                // ignore
            }

            int errno = 2000;

            errno = buf.readInt();

            String serverErrorMessage = buf.readString("ASCII", getExceptionInterceptor());

            StringBuffer errorBuf = new StringBuffer(Messages.getString(
                        "MysqlIO.10")); //$NON-NLS-1$
            errorBuf.append(serverErrorMessage);
            errorBuf.append("\""); //$NON-NLS-1$

            String xOpen = SQLError.mysqlToSqlState(errno,
                    this.connection.getUseSqlStateCodes());

            throw SQLError.createSQLException(SQLError.get(xOpen) + ", " //$NON-NLS-1$
                 +errorBuf.toString(), xOpen, errno, getExceptionInterceptor());
        }

        this.serverVersion = buf.readString("ASCII", getExceptionInterceptor());

        // Parse the server version into major/minor/subminor
        int point = this.serverVersion.indexOf('.'); //$NON-NLS-1$

        if (point != -1) {
            try {
                int n = Integer.parseInt(this.serverVersion.substring(0, point));
                this.serverMajorVersion = n;
            } catch (NumberFormatException NFE1) {
                // ignore
            }

            String remaining = this.serverVersion.substring(point + 1,
                    this.serverVersion.length());
            point = remaining.indexOf('.'); //$NON-NLS-1$

            if (point != -1) {
                try {
                    int n = Integer.parseInt(remaining.substring(0, point));
                    this.serverMinorVersion = n;
                } catch (NumberFormatException nfe) {
                    // ignore
                }
                
                //以下省略... 

这里的majorVersion 即 5代表MySQL 5， minorVersion即 MySQL 5.6 以上的6。再看看我们的数据库代理中间层，刚好有个server_version的配置，可以定制和客户jdbc交互的时候的MySQL版本比如设置为5.7.25-proxy，这样就可以满足业务小数秒的需求。如果读者相关业务有类似场景，也可以参考以上方式进行配置或者开发支持，改动也不大。

总结

以上就是本期文章的全部内容了，可以发现最近好几篇都和jdbc的驱动使用有关系。在使用中发现，有关jdbc驱动的资料相对来说比较少，很多的时候是通过踩坑积累的经验，后续看计划是否可以整理一个专门有关jdbc驱动原理和使用的手册，方便优化使用和开发理解。