老陈眨了眨他的眯眯眼，望向了我。
“是不是有用 int、有TIMESTAMP 还有 DATETIME 的？” 我早就发现了这个乱象，大家都各自设计各自的，没个统一的类型。
“对对对，你说应该选哪个好？”
老陈又要给我送温暖了，我赶紧回答道：“首先，这个 int 类型得先淘汰了，虽然从功能来说用 int 存储时间戳没毛病，不过最多就只能存到 2038 年，不过这也不知重点，今年才几几年，管那么多，指不定到时候项目都 G了。”
“重点是，int 用不了 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 和抗原，美滋滋：“果然知识就是金钱啊！古人诚不欺我！”
更过故事，请听下回分享！
