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

我有一个日志记录表，出于统计原因，它将包含数百万次写入。所有列都是int外键。我还将为每一行添加一个timestamp列。考虑到DATETIME需要8位，我将使用

int（10）unsigned

将存储空间（以及该列上的索引）减半

然而，我想知道这个专栏什么时候不再有效了。2038年1月19日凌晨3:14:07AM，UNIX时间戳的值9999999999将是一个问题-但是MySQL中的未签名int最多只能容纳4294967295，并且时间戳4294967295在我的PHP应用程序中显示了一个无效的数字

这是什么意思？在MySQL中存储int时间戳是否将在2021年结束，因为它无法一直保存到9999999999？

回答：

2147483647是2038（不是99999999），所以没有问题

无符号

是不需要的，因为2147483647适合于有符号的MySQL int

---

标准UNIX时间戳是一个有符号的32位整数，在MySQL中是一个常规的“int”列。无法存储9999999999，因为这远远超出了表示范围-任何类型的32位int的最高值都是4294967295。goes中有符号32位的最高值为2147483647

如果UNIX时间戳变为64位数据类型，则必须使用MySQL“bigint”来存储它们

---

至于

int（10）

，

（10）

部分仅用于显示目的。MySQL仍将在内部使用完整的32位来存储数字，但每当您在表上进行选择时，仅显示10。

我会担心的。；）即使您有1000万行，您也会额外使用9.5MB。。。只需使用DATETIME类型，真的。你应该记住DATETIME类型的目的是保护你根本不必处理这个问题。你们中的一些年轻人可能在2038年还活着，那时必须处理这些选择。；-）@他只是想确保2038年我们还有工作。继续努力，Xeoncross。我很高兴你肯定了我说的话，但这对于存储日期意味着什么呢？标准unix时间戳将进入PHP中的标准签名“int”列，而不进行任何转换。没有签名的unix时间戳——它不在标准的libc中，因此您不必担心2147483648->4294967295之间的时间戳。PHP的时间戳支持也直接基于libc，因此PHP也不会接受未签名的时间戳。这意味着不能以大于2^31-1的方式存储日期（即2147483647，可以表示2038年之前的秒数。9999999999将使您达到大约2287）。这是一个已知的问题；哦，那么答案是9999999999是不正确的，因为2038年的日期是不正确的（我的错），整数不需要不签名，因为2147483647适合MySQL签名的整数。所以，在2038年之前，我真的不必担心。除非你不需要处理未来的值。考虑一家银行工作30年抵押贷款报价。这将使抵押贷款在2040年结束，超过2038年的限额。如果/当64位开关发生时，我们将遇到Y292277026596K问题。但是，如果有人想安排我来修理它，我很乐意。