在使用new Date生成时间戳时,发现数据库中 的时间总是多出一秒钟。

项目汇报的时候,进一步研究问题

insert into t_tax_file(task_id, task_no, business_type, file_name, file_url, creator_id, created_time, modifier_id,
                       modified_time)
    value (10, 'taskNo测试', 1, '文件名称', '文件地址', 1, '2024-10-21 10:25:21.889', 1, '2024-10-21 10:25:21.449');
-- 方法二:使用 DATE_FORMAT 和 CONCAT 函数
SELECT  created_time,
       modified_time
FROM t_tax_file where task_no='taskNo测试';


差个一秒钟

image-20241021113445157

表结构

create table t_tax_file
(
    id            bigint unsigned auto_increment comment '主键'
        primary key,
    task_id       bigint                                    null comment '任务id',
    task_no       varchar(64)                               null comment '任务编号',
    business_type tinyint(1)                                null comment '业务类型',
    file_name     varchar(256)                              null comment '文件名称',
    file_url      varchar(500)                              null comment '文件url',
    creator_id    bigint unsigned default '0'               null comment '创建者id.对应员工id.',
    created_time  timestamp       default CURRENT_TIMESTAMP null comment '创建时间',
    modifier_id   bigint unsigned default '0'               null comment '修改id.对应员工id.',
    modified_time timestamp       default CURRENT_TIMESTAMP null on update CURRENT_TIMESTAMP comment '最后修改时间'
)
    comment '纳税申报-附件表';

mysql 5.6 之后的版本,timestamp 支持了微秒数。timestamp 和datetime区别

TIMESTAMP datetime
两者的存储方式不一样 对于TIMESTAMP,它把客户端插入的时间从当前时区转化为UTC(世界标准时间)进行存储。查询时,将其又转化为客户端当前时区进行返回。 而对于DATETIME,不做任何改变,基本上是原样输入和输出。
存储范围 timestamp,使用4个字节,所能存储的时间范围为:‘1970-01-01 00:00:01.000000’ 到 ‘2038-01-19 03:14:07.999999’。 datetime使用8个字节,所能存储的时间范围为:‘1000-01-01 00:00:00.000000’ 到 ‘9999-12-31 23:59:59.999999’。
注意点 MySQL中的TIMESTAMP数据类型用于存储日期和时间,支持小数秒精度,可以精确到微秒(即小数点后6位)。如果你在插入或更新TIMESTAMP列时没有指定小数部分,则默认精度是秒级,也就是不包含小数部分。

总结:TIMESTAMP和DATETIME除了存储范围和存储方式不一样,没有太大区别。当然,对于跨时区的业务,TIMESTAMP更为合适。

当指定了小数位数之后。

image-20241021114027514

数据就完全正确了

image-20241021114014502

测试其他数据类型

-- 创建表
-- 测试datetime的精度
CREATE TABLE test(
    -- 默认精度为0
    -- Maximum is 6.
                     datetime1 DATETIME,
                     datetime2 DATETIME(3),
                     datetime3 DATETIME(5)
);
INSERT INTO test VALUES("2020-11-22 12:01:01.59999", "2020-11-22 12:01:01.59999", "2020-11-22 12:01:01.59999");
INSERT INTO test VALUES("2020-11-22 12:01:01.5", "2020-11-22 12:01:01.599", "2020-11-22 12:01:01.59999");
INSERT INTO test VALUES("2020-11-22 12:01:01.4", "2020-11-22 12:01:01.594", "2020-11-22 12:01:01.59994");
INSERT INTO test VALUES("2020-11-22 12:01:01.5", "2020-11-22 12:01:01.5995", "2020-11-22 12:01:01.599995");
INSERT INTO test VALUES("2020-11-22 12:01:01.5", "2020-11-22 12:01:01.5994", "2020-11-22 12:01:01.599994");

image-20241021135238655

-- 创建表
-- 测试timestamp的精度
CREATE TABLE test11(
    -- 默认精度为0
    -- Maximum is 6.
    datetime1 TIMESTAMP,
    datetime2 TIMESTAMP(3),
    datetime3 TIMESTAMP(5)
);
INSERT INTO test11 VALUES("2020-11-22 12:01:01.59999", "2020-11-22 12:01:01.59999", "2020-11-22 12:01:01.59999");
INSERT INTO test11 VALUES("2020-11-22 12:01:01.5", "2020-11-22 12:01:01.599", "2020-11-22 12:01:01.59999");
INSERT INTO test11 VALUES("2020-11-22 12:01:01.4", "2020-11-22 12:01:01.594", "2020-11-22 12:01:01.59994");
INSERT INTO test11 VALUES("2020-11-22 12:01:01.5", "2020-11-22 12:01:01.5995", "2020-11-22 12:01:01.599995");
INSERT INTO test11 VALUES("2020-11-22 12:01:01.5", "2020-11-22 12:01:01.5994", "2020-11-22 12:01:01.599994");

image-20241021135430709

总结

类型 所占字节 格式 范围
TIMESTAMP 4字节 YYYY-MM-DD HH:MM:SS 1970-01-01 00:00:01utc到2038-01-19 03:14:07utc
DATETIME 5字节 YYYY-MM-DD HH:MM:SS 1000-01-01 00:00:00到9999-12-31 23:59:59
DATE 3字节 YYYY-MM-DD 1000-01-01到9999-12-31
TIME 3字节 HH:MM:SS -838:59:59到838:59:59
YEAR 1字节 YYYY 1901到2155

注:MySQL 5.6.4 之前,占 8 个字节 ,之后版本,占 5 个字节。

其他特性

  1. TIMESTAMP是以utc格式存储,会自动检索当前时区对时间进行转换,而DATETIME不会。
  2. 存入null时,TIMESTAMP会自动存储当前时间,而DATETIME存储null值。
  3. 时间计算:

DATETIME翻译为汉语即"时间戳",它是当前时间到 Unix元年(1970 年 1 月 1 日 0 时 0 分 0 秒)的秒数。对于某些时间的计算,如果是以 DATETIME 的形式会比较困难,假如我是 1994-1-20 06:06:06 出生,现在的时间是 2016-10-1 20:04:50 ,那么要计算我活了多少秒钟, DATETIME还需要函数进行转换,但是 TIMESTAMP 直接相减就行。

场景选择

1.需要跨时区计算时间用 或者 需要自动更新时间的TIMESTAMP

计算一架从北京飞往纽约的飞机的飞行时间。这个场景中,如果使用 TIMESTAMP 来存时间,起飞和降落时间的值,都会被转换成 UTC 时间,所以它们直接相减即可获得结果。但如果使用 DATATIME 格式存时间,还需要进行转换,才可以完成,容易出错。

2.记录创建修改时间 或者 时间范围大于2038 用DATETIME

DATATIME作为记录时间,现在都已经2022年了,很快就到2038年啦,使用DATATIME不需要担心超过范围。

当然在两者都满足使用的情况下,所占字节越小越好,TIMESTAMP比DATATIME好。

bigint使用(8个字节)

还有一种情况,即不用TIMESTAMP也不用DATATIME,而是用BIGINT。存储自纪元以来的毫秒数(如果使用的是 Java,则用 System.currentTimeMillis() 获取当前时间)

这样有几个优点:

  1. 可以在迁移数据库时避免因为数据类型差异。比如MySQL的DATETIME类型和Oracle的DATETIME类型之间可能存在差异,timestamp类型的精度可能也存在差异,MySQL的timestamp精度不是一开始就支持毫秒精度的。
  2. 没有时区问题。无论是哪个时区,因为开始计算的时间不同,无论当前时间如何,跨度是一致的。也没有timestamp和datatime的范围问题。是对timestamp的补充。
  3. InnoDB存储引擎下,通过时间范围查找,性能bigint > datetime > timestamp,通过时间排序,性能bigint > timestamp > datetime。综合来讲,bigint性能最好。

思考:

当发现问题,要把原因搞懂,然后进一步挖掘可以用的东西。不能浮于表面。

上一篇:低代码平台如何通过AI赋能,实现更智能的业务自动化?


下一篇:vue3中watch的用法以及使用场景以及与watchEffect的使用对比