TIMESTAMP和DATETIME的区别以及选择

首先我们看一下timestamp与datetime的对比如下：

类型	TIMESTAMP	DATETIME
不同点	存储空间：TIMESTAMP占用4个字节	存储空间：DATETIME占用8个字节
	时区：TIMESTAMP实际记录的是1970-01-01 00:00:01到现在的数数，受时区影响	时区：DATETIME不受时区影响
	时间范围：‘1970-01-01 00:00:01’ UTC ~ ‘2038-01-19 03:14:07’ UTC	时间范围:‘1000-01-01 00:00:00’ ~ ‘9999-12-31 23:59:59’
	存储方式：对于TIMESTAMP，它把客户端插入的时间从当前时区转化为UTC（世界标准时间）进行存储。查询时，将其又转化为客户端当前时区进行返回(中国属于东八区，所以应该是UTC+8）。	存储方式：而对于DATETIME，不做任何改变，基本上是原样输入和输出。

需要注意：

1.Datetime与timestamp的格式问题

答：两者都可用来表示YYYY-MM-DD HH:MM:SS[.fraction]类型的日期。
但是对于Datetime它可分为两部分：date部分和time部分，其中，date部分对应格式中的“YYYY-MM-DD”，time部分对应格式中的“HH:MM:SS[.fraction]”。对于date字段来说，它只支持date部分，如果插入了time部分的内容，它会丢弃掉该部分的内容，并提示一个warning。
具体可参照博客：https://www.cnblogs.com/ivictor/p/5028368.html

2.什么是UTC？

答：协调世界时，又称世界统一时间，世界标准时间，国际协调时间，简称UTC
不属于任意时区
中国大陆、中国香港、中国澳门、中国台湾、蒙古国、新加坡、马来西亚、菲律宾、西澳大利亚州的时间与UTC的时差均为+8，也就是UTC+8。
时区(Time Zone)是地球上的区域使用同一个时间定义。1884年在华盛顿召开国际经度会议时，为了克服时间上的混乱，规定将全球划分为24个时区。在中国采用首都北京所在地东八区的时间为全国统一使用时间。

例:已知东京(东九区)时间为5月1日12:00，求北京(东八区)的区时?北京时间=12:00-(9-8)=11:00(即北京时间为5月1日11:00)。

3.对于MySQL中timestamp数据类型的特点，为什么选择timestamp类型？？？

答：int类型占用4字节，datetime占用8字节，timestamp占用4字节；通常情况下在选择表中列的数据类型时我们要选择能满足存储需要的，最小的数据类型，在使用MySQL数据库时有很多常见的误解，其中使用int类型来保存日期数据会提高数据读取的效率就是比较常见的一个误解。显然INT要比datetime类型小很多，同时MySQL又提供了两个非常好用的函数FROM_UNIXTIME() 和UNIX_TIMESTAMP()，使用这两个函数可以方便的在INT和DATETIME类型之间进行转换，但是使用INT类型存储时间也给我们带来了不少的麻烦：

1.数据的可读性比较差，我们在查看数据时不能直观的看出时间列中记录的一串整数所代表的时间

2.每次进行显示时都要通过函数进行转换，增加了数据使用的复杂成度。

那有没有什么更好的方法来存储日期数据呢？这就要用到我们标题中所说到的timestamp类型了，timestamp类型的特点如下：
1.存储占用 4个字节，以年月日小时分秒的日期型式显示
2.存储范围’1970-01-01 00:00:01’ to ‘2038-01-19 03:14:07’.
3.以UTC时区进行存储，但是以系统当前时间进行显示
4.可以在insert和update时把值自动更新为当前时间

由以上特点可以知道，timestamp存储占用的空间和INT类型相同，实际上timestamp类型的数据在存储时就是被保存成INT类型的数据来存储的，这和我们使用INT来存储日期时间数据可以说是完全一样的。由于同样是使用INT类型来保存数据，所以和INT类型一样其存储的时间范围也是有限制的，
**这一点大家一定要注意，超过了这个范围的日期数据建议大家使用datetime类型来保存。**另外timestamp数据存储时是以UTC时区来保存的，在显示时MySQL会自动的把数据转换为当前连接所对应时间来显示。

可见，使用timestamp来存储日期时间数据不但保证了数据类型的大小同INT类型一样，同时可以显示为日期时间格式，这在给我们使用数据带来了很多的方便。所以强烈建议大家，使用timestamp类型来存储日期数据而不要再使用INT类型了。（转自：https://www.imooc.com/article/16158）