如何选择MySQL列数据类型以适应2038年-rollover？

Question

2038年1月19日03:14:07格林尼治时间现在还不到20年。这是UNIX 32位时间戳翻滚的时候。我正在设计一些可能当时仍在使用的MySQL表。

这就是所谓的2038年问题.

从我在MariaDB 10.3上尝试过的内容来看，使用TIMESTAMP数据类型会产生1292错误(不正确的日期时间值)，用于日期翻转后的数据存储。

将这些表设计成未来防伪的好方法是什么？我可以使用DATETIME数据，但是TIMESTAMP在时区方面有一些非常有用的特性。

MySQL的未来版本(更不用说Linux和其他UNIX衍生产品)是否有可能升级？

Answer 1

使用BigInts存储unix时间戳。这在功能上相当于时间戳类型，尽管缺少一些附加在它上的糖。但是，如果在应用程序级别上，您很高兴只使用UNIX时间戳，那么这一点都没有意义，至少到目前为止，在数据库层处理它与偶尔的UNIX_TIMESTAMP(…)是微不足道的。/ FROM_UNIXTIME(…)打电话。这将使你远远超过2038年。

虽然我希望MySQL / Maria暴徒会在X.y版本中创建一些黑客，它将自动更新TimeStamp字段，作为升级路径的一部分。请注意，它可能会在2038年1月18日发布。;)

无论如何，如果您想要将来的证明，BIGINT作为UNIX时间戳是您的答案。

Answer 2

把你1998年写的代码拿出来。找一台机器来运行它。您可能需要找到一个软盘驱动器来加载它。

现在，问问自己“20年后代码和硬件会发生什么变化”？

我建议，除了政府合同外，2018年编写的所有代码早在2038年之前就会被扔进垃圾桶。

在1998年，MySQL运行的是3.xx版本；我不想用10年(或20年)的杆数来碰它。从那时起，DATETIME的内部格式发生了变化，添加了CHARACTER SETs，添加了大量的优化，添加了子查询，修复了bug等。

我在最后一段中的观点是，随着MySQL在未来20年的成熟，您今天编写的任何东西都将经历应用程序更改。修复2038年的问题只是许多变化之一。

Answer 3

使用这两个函数并将时间戳存储为十进制。

CREATE FUNCTION from_unixtime_fixed (v DECIMAL(16,6))
    RETURNS DATETIME(6) DETERMINISTIC
    RETURN DATE_ADD(FROM_UNIXTIME(0), INTERVAL v second);
CREATE FUNCTION unix_timestamp_fixed (v DATETIME(6))
    RETURNS DECIMAL(16,6) DETERMINISTIC
    RETURN TIMESTAMPDIFF(SECOND, FROM_UNIXTIME(0), v);

样本使用:选择unix_timestamp_fixed('2039-01-01')；

返回2177449200.000000

select from_unixtime_fixed(2177449200.100000);

返回2039-01-01 00:00:00.100000

如果毫秒不感兴趣，将小数(16，6)降为小数(16，0)