unix 时间戳应该如何存储在 int 列中？答案

【问题标题】：How should unix timestamps be stored in int columns?unix 时间戳应该如何存储在 int 列中？
【发布时间】：2011-05-16 10:39:12
【问题描述】：

出于统计原因，我有一个包含数百万次写入的日志记录表。所有列都是 int 外键。我还将为每一行添加一个时间戳列。鉴于 DATETIME 需要 8 位 - 我将使用 int(10) unsigned 将存储空间（以及该列上的索引）减半。

但是，我想知道这个专栏什么时候不再有用。在 2038 年 1 月 19 日凌晨 3:14:07，值 9,999,999,999 将成为 UNIX 时间戳的问题 - 但 MySQL 中的 unsigned int 最多只能保存 4,294,967,295，并且时间戳 4294967295 在我的 PHP 应用程序中显示无效数字。

那么这是什么意思呢？ MySQL 中存储 int 时间戳的结束是否会在 2021 年某个时候结束，因为它无法一直到 9999999999？

答案：

2147483647 是 2038（不是 9999999999）所以没有问题。
unsigned 不需要，因为 2147483647 非常适合已签名的 MySQL int。

【问题讨论】：

那我会担心的。 ;)
即使你有 1000 万行，你也会使用额外的 9.5 MB... 只需使用 DATETIME 类型，真的。
您应该记住，DateTime 类型的目的是保护您根本不必处理这个问题。
你们中的一些年轻人可能仍然在 2038 年左右，届时必须应对这些选择。 ;-)
@Don，他只是确保我们在 2038 年还有工作。继续努力，Xeoncross。

标签： mysql datetime unix-timestamp

【解决方案1】：

标准 UNIX 时间戳是带符号的 32 位整数，在 MySQL 中是常规的“int”列。您无法存储 9,999,999,999，因为这超出了表示范围 - 任何类型的 32 位 int 的最高值是 4,294,967,295。最高的 32 位签名是 2,147,483,647。

如果/当 UNIX 时间戳转为 64 位数据类型时，您将不得不使用 MySQL“bigint”来存储它们。

对于int(10)，(10) 部分仅用于显示目的。 MySQL 仍然会在内部使用完整的 32 位来存储数字，但只要您在表上进行选择，就只会显示 10。

【讨论】：

我很高兴你肯定了我所说的，但是关于存储日期意味着什么的问题呢？
一个标准的 unix 时间戳将进入 PHP 中一个标准签名的“int”列，无需任何转换。没有签名的 unix 时间戳这样的东西 - 它不在标准 libc 中，因此您不必担心 2,147,483,648 -> 4,294,967,295 之间的任何时间戳。 PHP 的时间戳支持也直接基于 libc，因此 PHP 也不接受无符号时间戳。
这意味着您不能以大于 2^31-1 的方式存储日期（即 2147483647，它可以将时间表示为到 2038 年的秒数。9,999,999,999 将使您达到 2287 左右）。这是一个已知问题；stackoverflow.com/questions/36239/…
哦，那么答案是 9999999999 不正确，因为 2038 日期（我的错误）并且 int 不需要无符号，因为 2147483647 适合 MySQL 签名的 int。所以，在 2038 年之前我真的不用担心。
仅当您不需要处理未来值时。考虑一家从事 30 年期抵押贷款报价的银行。这使得抵押贷款在 2040 年结束，超过了 2038 年的限制。如果/当发生 64 位切换时，我们将遇到 y292,277,026,596k 问题。但如果有人想安排我在附近进行修理，我很乐意提供帮助。