日期是我们日常开发中经常用到的一种数据类型。一般来说，一张表有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还得慎重考虑。嗯，朋友们，留言告诉我你们日常开发日期用的是哪一种？您对这种类型有什么样的考虑？
