日期是我们日常开发中经常用到的一种数据类型。一般来说,一张表有createTime和updateTime字段。MySQL还为日期提供了许多不同的数据类型,例如datetimetimestampint等。有些人甚至将日期直接保存为字符串。那么应该使用哪种类型来保存日期呢?1.String在这些类型中,首先应该排除的就是字符串。很多新手朋友喜欢用字符串来存储日期,但其实这并不是一个很好的方案。使用字符串存储日期第一个明显的问题是不能使用MySQL中提供的日期函数,这会给很多查询带来不便。比如user表中有一个字段birthday,表示用户的生日。现在要查询2001年出生的所有用户,如果birthday是date类型,可以用YEAR函数,但是如果birthday是string类型,这个问题不太好解决。处理。使用字符串存储日期的第二个问题是它会占用大量空间。例如存储如下时间:2021-01-0100:00:00如果使用字符串,则需要19个字节。如果使用日期时间,则为8个字节。如果使用时间戳,则需要4个字节。所以首先排除字符串。2.DATETIMEVSTIMESTAMEP2.1占用空间DATETIME在数据库中的存储形式为:YYYY-MM-DDhh:mm:ss。至于占用多少字节,视情况而定。我们看MySQL官网的一段内容:可以看出MySQL5.6.4是一个分水岭:在MySQL5.6.4之前,DATETIME固定占用8个字节。从MySQL5.6.4开始,DATETIME类型开始支持毫秒。DATETIME(N)中的N表示毫秒的精度。例如,DATETIME(6)表示可以存储6位毫秒数。这时候DATETIME占用的字节数,跟后面的毫秒数有关。如果DATETIME不细到毫秒,会占用5个字节。如果细化到毫秒,则视情况而定。根据毫秒的精度,会占用不同的空间。当毫秒精度小于或等于2时,共占用6个字节;当毫秒精度小于或等于4时,共占用7个字节;当毫秒精度小于等于6时,一共占用8个字节。同样,从上图我们也可以看出,在MySQL5.6.4之前,TIMESTAMEP固定占用4个字节。从MySQL5.6.4开始,按照毫秒的精度,TIMESTAMEP占用的字节数在4到7之间。所以无论是TIMESTAMEP还是DATETIME,都比字符串节省空间。2.2存储范围DATETIME的存储范围在1000-01-0100:00:00到9999-12-3123:59:59之间。TIMESTAMP存储在1970-01-0100:00:01UTC和2038-01-1903:14:07UTC之间。显然DATETIME的存储范围更大。2.3底层存储TIMESTAMP类型最大的优势是它自带的时区属性,因为它本质上是由毫秒转换而来的。如果你的业务需要对应不同的国家时区,那么TIMESTAMP类型是一个不错的选择。TIMESTAMP类型字段的值会随着服务器时区的变化而变化,会自动转换成对应的时间。简单来说,就是在不同的时区,查询同一条记录时,该字段的值会不同。举个TIMESTAMP的使用场景例子:对于新闻业务,用户通常希望知道新闻发布时所在国家的时间,那么TIMESTAMP是一个不错的选择。TIMESTAMP会自动调整时区更改,而DATETIME则不会。举个例子:假设我的数据库当前时区是Asia/Shanghai:现在有一个user表,数据如下:其中createTime字段是DATETIME,updateTime是TIMESTAMP,现在我修改数据库时区,我们再查一下:buddy可以看到我设置的时区是东京,东京比我们早一小时。这时候updateTime自动改变,而DATETIME不变。时区问题一定要慎重,但是时区问题不一定要在数据库中解决,也可以在前端或者服务器端通过代码来处理。2.4性能对比毫秒转换成TIMESTAMP并不麻烦,但是当需要进行时区转换时,需要调用操作系统底层的系统函数,而这个函数需要额外的加锁操作,以保证时间戳的时区此时尚未修改操作系统。一旦锁定,效率低下。对于这个问题,只存在于TIMESTAMP,因为DATETIME不存在时区转换问题。对于TIMESTAMP,建议使用明确的时区而不是操作系统时区。3、int型字符串占空间,TIMESTAMP和DATETIME如果理解不透,总会觉得很乱,所以有人存时间戳,存一个int类型的值,用时间戳来表示时间。如果我们用int来节省时间,当我们需要对日期进行排序,按照日期范围查询时,就变成了普通的数字比较,效率一定很高。但是int有一个致命的问题就是可读性太差,所以要不要用int还得慎重考虑。嗯,朋友们,留言告诉我你们日常开发日期用的是哪一种?您对这种类型有什么样的考虑?
