Question

我不想在使用DATETIME与TIMESTAMP与INT之间开始另一个关于赞成或反对的讨论。（我已经阅读了Using MySQL's TIMESTAMP vs storing timestamps directly等文章。）

我有时会使用INT数据类型在数据库中存储unix时间戳。这是因为我的应用程序中的日期和时间计算经常使用unix时间戳（例如，对于会话超时和令牌到期）。此外，当我可以简单地比较DATETIME子句中的整数值时，数据库中的数据选择比使用WHERE更快。很少有表有超过100万行（高达1亿），其中4个字节确实可以节省存储空间（因为索引较小，在磁盘和内存中）。

关于Y2K38问题，我假设（并希望如此），MySQL中的UNIX_TIMESTAMP和PHP中的time()将来会返回64位值，因此不需要在应用程序中更改某些内容本身。关键是，我将所有这些伪整数时间戳存储在MySQL中作为无符号整数（我的意思是INT而不是BIGINT）。当然，无符号整数时间戳将在2106年溢出，但这比2038年更多。

我现在的问题是：假设UNIX_TIMESTAMP本身在2038年之后可以正常工作，那么MySQL和/或PHP会出现任何问题，直到2106这些时间戳在MySQL中存储为无符号整数？（请不要争辩：将有很多时间来解决这个问题，直到2038年，我想从应用程序的角度来澄清这一点，不再触及）

编辑：因为问题出现了：我只在这些列中存储当前时间戳，没有生日，没有未来日期。只有当前的时间戳，所以我想澄清这是否会在2038年之后起作用。

Answer 1

您对UNIX_TIMESTAMP（）的假设非常重要。

目前，如果您尝试

，UNIX_TIMESTAMP将返回0

mysql> select unix_timestamp("2038-01-19" );
+-------------------------------+
| unix_timestamp("2038-01-19" ) |
+-------------------------------+
|                    2147468400 |
+-------------------------------+
1 row in set (0.00 sec)

mysql> select unix_timestamp("2038-01-20");
+------------------------------+
| unix_timestamp("2038-01-20") |
+------------------------------+
|                            0 |
+------------------------------+
1 row in set (0.00 sec)

虽然长度超过32位的INT的存储将起作用，除非你知道unix_timestamp（int64）的实现将如何工作，否则问题实际上是猜测而不是事实。

这意味着您执行的任何整数运算仍将对64位整数有效，因此查找过期的会话（时间戳+超时＆lt;（自1970年以来的64位以来的秒数））仍然有效。您是否可以依赖from_unixtime（）和unix_timestamp（） - 函数取决于解决方案是仅仅是将赌注提高到64位还是整个世界在接下来的20多年内决定设置一个新纪元。 / p>

没人知道。

将unix时间戳存储为无符号整数会有什么好处吗？

1 个答案: