查看原文
其他

数据库存储时间到底该用什么类型?

是Yes呀 yes的练级攻略 2023-01-02

“yes,最近设计一个新项目的数据库表结构,别的项目以前的表,发现这个时间字段类型都没个统一,我有点麻了。”

老陈眨了眨他的眯眯眼,望向了我。

“是不是有用 int、有TIMESTAMP 还有 DATETIME 的?” 我早就发现了这个乱象,大家都各自设计各自的,没个统一的类型。

“对对对,你说应该选哪个好?”

老陈又要给我送温暖了,我赶紧回答道:“首先,这个 int 类型得先淘汰了,虽然从功能来说用 int 存储时间戳没毛病,不过最多就只能存到 2038 年,不过这也不知重点,今年才几几年,管那么多,指不定到时候项目都 G了。”

“重点是,int 用不了 DEFAULT CURRENT_TIMESTAMPON UPDATE CURRENT_TIMESTAMP。”

DEFAULT CURRENT_TIMESTAMP

当记录插入的时候,如果没有指定时间,那么默认填入当前时间。

ON UPDATE CURRENT_TIMESTAMP

当记录修改时,自动更新时间,相当于自动修改记录的更新时间,不需要人为塞值。

这两个玩意就很好使了,非常方便,不然相关的 SQL 你都得显示的写入插入和修改当前时间的语句。

麻烦!且容易漏!编程这玩意最重要的是简单、便捷,花里胡哨的都容易出错。

老陈听完,煞有其事地点了点头,示意我继续。

鱼儿已经上钩,我怎能轻易放过!

我故作停顿,瞟了眼他桌上的抗原检测试剂,这玩意最近可是硬通货,网上压根买不着了。

老陈心领神会,双手捧着一盒,轻轻地放在我的桌上。

我点了点头,继续说道:“至于 TIMESTAMP 的话,5.6版本以上支持 TIMESTAMP(N) N 表示秒的小数位,最高可达六位,不过它也只能存到 2038 年,本质上跟 int 一样,都是时间戳,不过数据库可以操作它进行时区的转换!”

时间戳存的就是'1970-01-01 00:00:00' 到现在的毫秒数,没有时区的概念,而 MySQL 的 TIMESTAMP 类型可以指定时区返回不同的时间。

简单点,我拿 SELECT NOW() 来举例不同时区的情况。

比如我现在不指定时区,默认就是操作系统的时区,返回的结果如下图所示:

然后我现在整个把时区变成卡塔尔的,你看看,时间是不是就变了?TIMESTAMP  就是有这样的功效。

老陈定睛一看,冷不丁地冒出一句:“这丫的世界杯时间真不友好,老是在我们凌晨 3 点踢,你看看,熬的我都长痘痘了!破坏我英俊的脸庞!”

“话说回来,这时区功能不是必备的呀,我在服务端转个时区不就得了嘛?”

我嫌弃地瞄了他一眼,忽略他的臭美:“没错,如果有分时区的需求,服务端直接转时区塞给前端就行了,而且利用 MySQL 转时区还有小坑!”

因为 TIMESTAMP 绑定了时区的属性,所以每次都需要利用时区来计算时间,如果我们 MySQL 没有指定时区,那么默认就需要每次查看操作系统的时区,就得调用操作系统底层的 __tz_convert 函数,会加锁,而加锁就意味着资源争抢!

在高并发的时候,影响可能就会比较大了!

所以如果非要用 TIMESTAMP ,那么记得在 MySQL 配置文件中显示设置时区!

“OKOK,那我就不用 int 也不用 TIMESTAMP ,就用 DATETIME 了!不会这玩意也不好使吧?”

我搓了搓手,又瞄向了他桌上刚收到的快递,看这包装好像是 KN95 口罩?

老陈顺着我的目光,心疼地移步向前拆开包装扔给了我一包,骂骂咧咧道:“这狗日的口罩,现在不仅难买还很贵,这玩意前不久还 1 块钱,现在要 5 块!真是些黑心商家!”

“可不嘛,我在网上下了十几单,涨价我忍了,还都是预售的!发货时间1-45天内....”我吐槽道,“行了,不扯这个,继续说 DATETIME。”

DATETIME 没有 2038 的限制,可以存到 9999-12-31 23:59:59,也没有时区属性,并且支持 DEFAULT CURRENT_TIMESTAMPON UPDATE CURRENT_TIMESTAMP

DATETIME(N) 中的 N 表示秒的小数位,最高可达 6 位,也是 5.6 版本以上支持。

这个 N 可能光说你没直观的影响,我还是拿 SELECT NOW 举个例子:

所以 DATETIME 其实没啥缺点,如果非要说个的话可能就是空间的占用了相比会大些了,看下下面这个图:

对了,上图还有个 DATE 类型,这个就不说了,只能存储日期,无法存储时分秒。

老陈摸了摸他的大光头,“懂了,问就是 DATETIME!”

孺子可教!

我埋头理了理桌上的 KN95 和抗原,美滋滋:“果然知识就是金钱啊!古人诚不欺我!”

更过故事,请听下回分享!


有些同学如果私下在做实验在设置时区时候可能会遇到 unknown variable 'time_zone=Asia/Qatar' 这样的错误。

原因是你的 MySQL 没有初始化时区相关的信息,时区初始化的 sql 我放在公众号后台了,有兴趣的回复【时区】就能拿到文件,适用于 5.7+版本,直接跑就行。

我是yes,从一点点到亿点点我们下篇见~

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存