13 mysql date/time/datetime/year 的数据存储

前言

这里主要是 由于之前的一个 datetime 存储的时间 导致的问题的衍生出来的探究 

探究的主要内容为 int 类类型的存储, 浮点类类型的存储, char 类类型的存储, blob 类类型的存储, enum/json/set/bit 类类型的存储 

本文主要 的相关内容是 datetime/date/time/year 类类型的相关数据的存储  

这部分数据 客户端 和 服务器这边的交互 主要是以字符串的形式交互 

服务器这边的存储 将日期编码为 整形进行存储 

 

最近碰到了一个这样的一个问题

主要是在一个 增量同步的地方, 增量同步 tableA, 增量查询字段为 create_time, 类型为 datetime

然后 业务组件中 select max(create_time) from tableA 中查询到的最大时间 居然比实际的最大时间 多了 13 个小时, 呵呵

然后 这就导致了 增量同步存在问题

下一次增量同步的时候, 将 增量同步的最大值更新为了 13个小时以后, 这样 根据这个时间去做增量查询 接下来的 13 个小时的任务执行 都查询不到 需要增量同步的记录

然后 最终是发现 服务器的 default-time-zone 被调整了, 重置一下 default-time-zone 即可 

我这里 mysql 服务器版本为 5.7.31

 

 

mysql 中 datetime 的数据交互

创建表 以及插入测试数据

CREATE TABLE `tz_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `field1` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

INSERT INTO `test`.`tz_test`(`id`, `field1`) VALUES (1, '2023-04-24 16:25:40');

 

测试脚本如下 

package com.hx.test07;

/**
 * Test06MysqlTimezone
 *
 * @author Jerry.X.He
 * @version 1.0
 * @date 2023/4/24 16:26
 */
public class Test06MysqlTimezone {

    // Test06MysqlTimezone
    public static void main(String[] args) {

        String url = "jdbc:mysql://10.60.50.16:3306/test?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&autoReconnectForPools=true&useSSL=false";
        String username = "root";
        String password = "root";
        JdbcTemplate jdbcTemplate = Test14GenExpertSql.getMysqlJdbcTemplate(url, username, password);

        String sql = " select * from tz_test; ";
        List> list = jdbcTemplate.queryForList(sql);
        int x = 0;


    }

}

 

抓包拿到 mysql 响应解析如下 

可见这里 wireshark 解析貌似是存在问题的, 前两个 packet 对应的是 字段列表的元数据 

第三个 packet 是具体的数据, 包含了 packetLength, packetNumber, 字段id, 字段field1

第四个 packet 是 eof 包 

 

业务查询从服务器拿到的数据部分的如下, 可以看到的是 和上面一致

可以看到的是 datetime 的交互是通过字符串的形式交互的, 因此 存取的时候的转换都是服务器自己处理的

第一个字节 01 表示 id 数据长度 1 

第二个字节 31 表示 id 为 1

第三个字节 13 表示 field1 数据长度 19

剩余十九个字节为 “2023-04-24 16:25:40”

 

再看一下 insert into 存放数据的时候的相关 包的情况

整个 sql 语句是通过字符串的形式 交互给 mysql, mysql 自行解析 处理

 

 

所以 客户端这边拿到的 datetime 的字符串 取决于服务器的时区配置, 以及客户端请求的时区配置 

我们这边调整一下 客户端这边的 serverTimezone 的配置, 整个 url 更新成为

jdbc:mysql://10.60.50.16:3306/test?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&autoReconnectForPools=true&useSSL=false&serverTimezone=GMT%2B2

 

查看一下 服务器响应的数据

服务器相应的依旧是字符串的 “2023-04-24 16:25:40”

所以说这个 serverTimeZone 的转换是在客户端这边 

 

客户端这边具体的时间转换是在这里, 服务器响应回来的时间是 “2023-04-24 16:25:40”

按照 GMT+2 的时间转换为时间戳为 “1682346340906”

换算成 我们 GMT+8 的时间为 “2023-04-24 22:25:40”

 

具体获取时区的地方, 是从 session 的 serverTimeZone 获取的, 也就是我们上面指定的 serverTimeZone

 

业务这边查询, 拿到的是时间戳为 “1682346340906”

然后按照 GMT+8 转换一下 “2023-04-24 22:25:40”

 

 

 调整 mysql 的 default_time_zone

--default_time_zone='+02:00'

增加默认时区的配置, 然后 再来查看一下 情况

服务器这边 响应回来的数据, 依然是 “2023-04-24 16:25:40”

 

然后客户端这边 按照 GMT+2 转换为时间戳

所以说 这里 serverTimeZone 可能取自两个地方, 一个是服务器, 一个是客户端 

 

可以看到这里 拿到的 field1 结果也是 

GMT+2 的 “2023-04-24 16:25:40”

GMT+8 的 “2023-04-24 22:25:40”

 

我们来看一下这里 获取 serverTimeZone 的地方 

优先获取的是 客户端配置的 timeZone

其次获取的是服务器的 timeZone, 有两种配置方式 

 

服务器这边的变量是用如下 sql 查询的, 并注册到 serverVariables 中 

 

查询的 sql 如下 

SELECT  @@session.auto_increment_increment AS auto_increment_increment, @@character_set_client AS character_set_client, @@character_set_connection AS character_set_connection, @@character_set_results AS character_set_results, @@character_set_server AS character_set_server, @@collation_server AS collation_server, @@collation_connection AS collation_connection, @@init_connect AS init_connect, @@interactive_timeout AS interactive_timeout, @@license AS license, @@lower_case_table_names AS lower_case_table_names, @@max_allowed_packet AS max_allowed_packet, @@net_write_timeout AS net_write_timeout, @@performance_schema AS performance_schema, @@query_cache_size AS query_cache_size, @@query_cache_type AS query_cache_type, @@sql_mode AS sql_mode, @@system_time_zone AS system_time_zone, @@time_zone AS time_zone, @@transaction_isolation AS transaction_isolation, @@wait_timeout AS wait_timeout

 

 

与客户端的交互, 获取给定的 datetime 的编码之后的 longlong 表示 

然后再 解码为目标格式 的字符串表示

 

格式化的模板为 yyyy-MM-dd HH:mm:ss

 

 

mysql 服务器 datetime 的数据存储 

然后 我们来看一下 mysql 这边 datetime 字段的存储, 测试语句如下

客户端交互 字符串过去, 服务端拿到 这个字符串会做什么处理呢?

insert into tz_zone (field1) values ('2023-04-24 16:25:40');

 

首先如下地方是 将字符串转换为 MYSQL_TIME 的结构体, 处理就是解析出 年月日, 时分秒 等等信息 放到 MYSQL_TIME 中

 

解析之后 MYSQL_TIME 中存储了传入 时间所表示的 年月日, 时分秒 等等信息

 

这是具体的存储方案, 将 MYSQL_TIME 编码成为一个 longlong

存储方案 在备注中 解释的很明确

/*
    1 bit  sign            (used when on disk)
   17 bits year*13+month   (year 0-9999, month 0-12)
    5 bits day             (0-31)
    5 bits hour            (0-23)
    6 bits minute          (0-59)
    6 bits second          (0-59)
   24 bits microseconds    (0-999999)

   Total: 64 bits = 8 bytes

   SYYYYYYY.YYYYYYYY.YYdddddh.hhhhmmmm.mmssssss.ffffffff.ffffffff.ffffffff
*/

 

 

 

然后 响应就是一个逆向的过程

首先 还原成 MYSQL_TIME

然后 再转换成为字符串

整个过程中可以理解为 对于时间字符串的 编码, 解码

抽象这个编码解码的过程, 可以理解为 服务器这边 存放 datetime 就是存放的一个字符串, 所以说 服务器这边 datetime的存放是不涉及时区的

 

 

mysql 中 date/time/year 的机制和 datetime 类似 

com.mysql.cj.result 相关实体是将协议的 字节序列 转换为 具体的基础数据类型的数据

 

date

 

time

 

 year

 

timestamp

 

 

date 的格式化 

 

 

 year 的格式化

 

 

完