不用到2038年，MySql的TIMESTAMP就能把我们系统搞崩

历史文章推荐：

1. 细数ThreadLocal三大坑，内存泄露仅是小儿科
2. Java 8 ConcurrentHashMap源码中竟然隐藏着两个BUG
3. ConcurrentHashMap中有十个提升性能的细节，你都知道吗？
4. HashMap面试，看这一篇就够了
5. 七种方式教你在SpringBoot初始化时搞点事情
6. Java序列化的这三个坑千万要小心

MySql中常见的时间类型有三种DATE, DATETIME和 TIMESTAMP，其中DATE类型用于表示日期，但是不会包含时间，格式为YYYY-MM-DD，而DATETIME和TIMESTAMP用于表示日期和时间，常见的格式为YYYY-MM-DD HH:MM:SS，也可以带6位小数来表示微秒。不同于DATETIME，TIMESTAMP支持的时间范围从1970-01-01 00:00:01.000000到2038-01-19 03:14:07.999999，使用了TIMESTAMP的应用很有可能在2038-01-19 03:14:07.999999之后宕机，同样面临这个问题的还有所有的类Unix系统，因为他们使用了time_t这一32位数字来表示时间，这就是著名的2038问题。

因为时间问题搞坏系统的例子可不少，在2016年曾经爆出过一个iPhone的bug，如果将iPhone的时间调整到1970-01-01 00:00:00，则会导致手机”变砖“，原因是IOS基于BSD这种Unix系统构建，在将时间调整到1970-01-01 00:00:00后，如果手机需要展示之前的时间，例如之前收到过短信，则会导致整数溢出。对于2038问题，Linux的解法是提供新的用户接口：https://www.ithome.com.tw/news/103902.但是MySql至今还没有相应的公告。

TIMESTAMP的设计之初是为了支持自动时区转换：

mysql> CREATE TABLE `employee` (
    ->  `entry_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
    -> ) ENGINE=InnoDB
    -> ;
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO `employee` (`entry_time`) VALUES (CURRENT_TIMESTAMP);
Query OK, 1 row affected (0.01 sec)

mysql> SELECT * FROM `employee`;
+---------------------+
| entry_time          |
+---------------------+
| 2021-05-09 08:14:08 |
+---------------------+
1 row in set (0.00 sec)

mysql> SET @@session.time_zone = '-05:00'; SELECT * FROM `employee`;
Query OK, 0 rows affected (0.00 sec)

+---------------------+
| entry_time          |
+---------------------+
| 2021-05-09 03:14:08 |
+---------------------+
1 row in set (0.00 sec)

但是TIMESTAMP的一些设计却非常鬼畜，比如：

• 如果表中包含TIMESTAMP的列，那么其建表语句有可能被系统篡改，取决于MySql的版本和参数设置。
• 当MySQL参数time_zone=system时，高并发可能会引起CPU使用率暴涨，系统响应变慢甚至假死
• 如果存入超过范围的时间