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

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

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

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

“对对对，你说应该选哪个好？”

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

“重点是，int 用不了 DEFAULT CURRENT_TIMESTAMP 和 ON 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_TIMESTAMP 和 ON 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，从一点点到亿点点我们下篇见~