mysql储存时间选择怎样的字段类型

储存时间,常用的有三个选择datetimetimestampint。昨夜同事问到了,于是今天就总结一下自己的理解。

  1. 插入效率:datetime > timestamp > int
  2. 读取效率:int > timestamp > datetime
  3. 储存空间:datetime > timestamp = int
具体上面的实验数据可以看这篇文章
建立索引的体积,和索引的速度,你懂的。

让我们来看一个应用场景:
QQ截图20120601102859.png
看下这张图,第一我们需要设置系统的默认时区,第二我们也需要提供不同时区时间显示的需要。于是,我们分别使用datetimetimestampint字段类型来看下:

使用datetime

直接显示时间,这是个不错的选择,但是如果考虑到时区,很明显计算上的麻烦。

使用timestamp

OK,这个很好,可以根据系统的时区来自动输出时间,但是单个用户要定制自己的时区呢?再者你不怕麻烦,在程序里面实现了这个计算,服务器若是换个地方,改了下时区,你程序里面计算单个用户当地时间的代码怎么办(timestamp出来的时间会根据时区的变化而变化,在某些情况下是不错的选择,但在某些情况下,真的很鸡肋)。

使用int

从上面两个类型的缺点看来,貌似这个类型可以解决以上的问题,其实我们只要存格林时间的unix timestamp就好了,时区时间的计算上也很方便,读取的效率也不错。我觉得用这个储存的缺点呢,就是直接select的时候时间不能直观的显示出来。

看看其他开源程序是怎么做的

discuz, typecho, emlog等等等等,他们都选用int了,这一定有他们的道理,我想也没什么可以多说的了。

标签: none

已有 3 条评论

  1. 支持一下!

  2. 熊

    感谢你的帮助,
    我认为使用哪一种是要根据应用场景,包括考虑到三种类型的性能及空间(索引);
    如果,时间是用于记录数据的创建时间,时区的概念就会弱一些,因为没有业务上的需要。
    如果,时间是用于保存跟业务相关的时间且时间非常重要时,比如你的生日,下订单的时间,某件事情发生的时间,约定开会的时间,其在业务已确定而没有实施时,做时区的转换是不合理的,你的生日是19960123,需要时区转换吗?约定开会的时间需要时间转换吗(开会者约定的时间是跟开会者地区有关)?定单也是一样,用户只记得下定单的时间,应该是客户端给出,而不是到服务器端去转换时区,例如:你看手表是20120531 220000下的定单,假设服务器是在英国,你希望下次打开你的定单你的时间已经变化了吗?用户的体验会如何?

    所以,我认为datetime是最好的记录时间类型;
    int 显示有问题,业务上的技术支撑不足。
    timestamp 时区转换较为可能影响业务及用户体验,不可取。
    datetime 不存在相应问题

    1. 约定开会的时间 开会者可以处于世界各地 转换为当地的时间是必须的, 至于显示,直接查看数据的时候,完全没有看时间的必要,具体时间可以在程序中计算出来。当然选择datetime是可以的,只是如文中所说的,计算麻烦。

添加新评论