mysql储存时间选择怎样的字段类型
储存时间，常用的有三个选择datetime、timestamp、int。昨夜同事问到了，于是今天就总结一下自己的理解。
- 插入效率：datetime > timestamp > int
- 读取效率：int > timestamp > datetime
- 储存空间：datetime > timestamp = int
建立索引的体积，和索引的速度，你懂的。
让我们来看一个应用场景：
看下这张图，第一我们需要设置系统的默认时区，第二我们也需要提供不同时区时间显示的需要。于是，我们分别使用datetime、timestamp、int字段类型来看下：
使用datetime
直接显示时间，这是个不错的选择，但是如果考虑到时区，很明显计算上的麻烦。
使用timestamp
OK,这个很好，可以根据系统的时区来自动输出时间，但是单个用户要定制自己的时区呢？再者你不怕麻烦，在程序里面实现了这个计算，服务器若是换个地方，改了下时区，你程序里面计算单个用户当地时间的代码怎么办（timestamp出来的时间会根据时区的变化而变化，在某些情况下是不错的选择，但在某些情况下，真的很鸡肋）。
使用int
从上面两个类型的缺点看来，貌似这个类型可以解决以上的问题，其实我们只要存格林时间的unix timestamp就好了，时区时间的计算上也很方便，读取的效率也不错。我觉得用这个储存的缺点呢，就是直接select的时候时间不能直观的显示出来。
看看其他开源程序是怎么做的
discuz, typecho, emlog等等等等，他们都选用int了，这一定有他们的道理，我想也没什么可以多说的了。
支持一下！
感谢你的帮助，
我认为使用哪一种是要根据应用场景，包括考虑到三种类型的性能及空间（索引）；
如果，时间是用于记录数据的创建时间，时区的概念就会弱一些，因为没有业务上的需要。
如果，时间是用于保存跟业务相关的时间且时间非常重要时，比如你的生日，下订单的时间，某件事情发生的时间，约定开会的时间，其在业务已确定而没有实施时，做时区的转换是不合理的，你的生日是19960123，需要时区转换吗？约定开会的时间需要时间转换吗（开会者约定的时间是跟开会者地区有关）？定单也是一样，用户只记得下定单的时间，应该是客户端给出，而不是到服务器端去转换时区，例如：你看手表是20120531 220000下的定单，假设服务器是在英国，你希望下次打开你的定单你的时间已经变化了吗？用户的体验会如何？
所以，我认为datetime是最好的记录时间类型；
int 显示有问题，业务上的技术支撑不足。
timestamp 时区转换较为可能影响业务及用户体验，不可取。
datetime 不存在相应问题
约定开会的时间 开会者可以处于世界各地 转换为当地的时间是必须的， 至于显示，直接查看数据的时候，完全没有看时间的必要，具体时间可以在程序中计算出来。当然选择datetime是可以的，只是如文中所说的，计算麻烦。