从前慢现在也慢

这个屌丝很懒，什么也没留下！

热门标签

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

作者：从前慢现在也慢 | 2024-08-10 17:25:45

踩

前言

这里主要是由于之前的一个 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<Map<String, Object>> 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
*/