MySQL 时间字段用 int 、 datetime 还是 timestamp？

其实我以前也经历过这样的事情。
我记得有一年，我在一个项目中使用INT类型存储时间戳，出了问题。
该项目是在北京完成的。
我们有一个1 0人的团队，花了半年的时间才完成。

当时我们觉得INT类型存储时间戳非常方便。
不需要处理额外的格式，直接排序查询速度非常快。
结果项目上线后，客户反映时间显示有问题，有时不准确。
经过检查，发现INT类型时间戳在不同服务器、不同时区显示的时间不同。
这太令人难以置信了。

后来不得不改用DATETIME类型，它格式统一，更容易阅读，而且还可以处理时区问题。
从此以后，我再也不敢在项目中乱搞时间类型了。
现在回想起来，DATETIME 其实是一个不错的选择。
直接支持日期格式，格式固定，运行效率够用。
正确处理时区而不用担心数据溢出或 Y2 K 问题非常重要。

所以兄弟，以后使用MySQL存储时间字段的时候，建议使用DATETIME类型。
我自己也有过这样的经历。

mysql中日期类型DATETIME和TIMESTAMP的区别

MySQL中DATETIME和TIMESTAMP实际上有很多区别。

存储格式及范围： DATETIME 以“YYYYMMDDHH:MM:SS”格式存储，例如“2 02 3 01 01 1 2 :3 0:00”。
范围很广，从“1 00001 01 00:00:00”到“9 9 9 9 1 2 3 1 2 3 :5 9 :5 9 ”。
时间戳不同。
它存储从 1 9 7 0 年 1 月 1 日到现在的秒数。
例如，“2 02 3 01 01 1 2 :3 0:00”可能存储 4 3 3 3 4 3 2 3 0 秒。
该范围不如 DATETIME 大，并以“2 03 8 01 1 9 03 :1 4 :07 ”UTC 结束。

时区的处理也完全不同： DATETIME 保存时不包含时区信息。
这就是被保存的东西。
我检查的时候还是一样。
与计算机确定的时区无关。
TIMESTAMP 在保存时将转换为 UTC，然后在选择时转换回当前时区。
因此，如果您将时区设置为北京，那么您保存的数据在纽约查看时将是正确的。

自动配置和更新： DATETIME 无法自动设置当前时间。
如果要插入数据，则必须手动填写时间。
更新记录时时间本身不会改变。
TIMESTAMP可以设置在输入数据时自动填充当前时间，并在数据更新时自动更改时间。
例如，创建表时可以这样写： SQL TIMESTAMP DEFAULT CURRENT_TIMESTAMP 当每次插入或更新数据时更新 CURRENT_TIMESTAMP
时，此列将自动填充当前时间。

存储空间也不同： DATETIME 占用 8 个字节，而 TIMESTAMP 仅占用 4 个字节。
时间戳节省空间。

说实话，选择哪一个要看情况。
如果您想保存历史事件或其他内容，并且需要精确到秒，而不必担心时区，那么 DATETIME 是一个不错的选择。
如果存储用户的登录时间、订单更新时间等，应该自动获取时区，TIMESTAMP 更方便。