《MySQL-时间是用时间戳还是日期格式》

起步 这是一个架构权衡的问题。它不是从性能上去考虑的。时间戳到日期的互转只是简单的计算，消耗的计算量远远达不到其他地方。Mysql 内置了 timestamp 和 datetime 两个类型供开发者选择。这种类型要选哪个比较合适？这个时候首先要问自己，是不是要保存 1970 年以前的时间，如果是，那么就必须采用 datetime了，没有其他选择。这点以外，我更喜欢用时间戳，因为它能避免很多日期类型带来的问题。

日期时区问题

若应用涉及了多时区，那么保存日期格式会很麻烦，单单时区的设置就有操作系统设置的时区、后端语言设置的时区、数据库设置的时区。这转换关系足可以绕晕开发者，如果应用还是分布式多服务器的，那简直是爆炸啊。

保存时间戳则不会有这个问题，在世界任何时区里同一时间取得时间戳都是相同的，显示的时候也就多一个转换而已，绝对的物超所值。

日期格式不统一

01-01-2020 说不清是月在前还是日在前。有的开发者喜欢用 / 做分隔符。不过这点一般有统一的开发文档就不会成为问题。

麻烦的是如果前端要求显示 Y年m月d日 的形式呢，那后台就得日期->时间戳->日期，反而不如一开始就存时间戳。

日期是会变的

这点其实很奇葩，概率很低，主要是人为的修改时区，比如 委内瑞拉：时间在2007年12月9日倒退30分钟，见新闻: https://www.timeanddate.com/news/time/venezuela-enters-half-hour-zone.html ，大致是说委内瑞拉从时区是UTC-4小时改为了UTC-5小时。

尽管这种事非常少见，但至少说明了日期时间是会发生变化的。

日期格式不利于升级

Mysql 5.6 的 datetime 允许保存 0000-00-00 的数据，但在 5.7 则不允许，这种情况下旧数据就不好迁移到新环境了。

时间戳应选用 bigint
mysql 的 timestamp 用的还是 4 个字节存储，因此它会有 2038年问题 ，对此mysql官方还没给出解决方案，新方案如果是在新版本中解决的，那么对于无法升级的应该也是个灾难。

总结
时间戳是存时间的首选，但 datetime 也是未来的一个趋势，在 Django 应用中我还是很乐意用日期类型的，Django 很好的解决了时区的问题。相信在不久的未来，会有越来越完善的第三方组件帮助开发者解决时区问题后，datetime 也会越来越多的人使用。