unix 时间戳应该如何存储在 int 列中？
我有一个日志表，出于统计原因，其中将包含数百万次写入。所有列都是 int 外键。我还将为每一行添加一个时间戳列。鉴于 DATETIME 需要 8 位 - 我将使用 int(10) unsigned 将存储空间（以及该列上的索引）减少一半。
不过，我想知道这个专栏什么时候不再起作用。 2038 年 1 月 19 日凌晨 3:14:07，值 9,999,999,999 对于 UNIX 时间戳来说将是一个问题 - 但 MySQL 中的无符号整数最多只能保存 4,294,967,295，而时间戳 4294967295 在我的 PHP 应用程序中显示无效数字。
那么这是什么意思呢？ MySQL 中存储 int 时间戳的结束时间是在 2021 年的某个时候，因为它无法一直达到 9999999999？
答案：
- 2147483647 是 2038（不是 9999999999），所以没有问题。
- 不需要
unsigned因为 2147483647 非常适合签名的 MySQL int。
I have a logging table that will contain millions of writes for statistical reasons. All the columns are int foreign keys. I am also going to add a timestamp column for each row. Given that DATETIME takes 8bits - I will be using int(10) unsigned to cut the storage space (and index on that column) in half.
However, I'm wondering when this column would no longer work. At 3:14:07AM on 19th January 2038 the value 9,999,999,999 will be a problem for UNIX timestamps - but an unsigned int in MySQL only holds up to 4,294,967,295 and the timestamp 4294967295 is showing an invalid number in my PHP application.
So what does this mean? Is the end of the storing int timestamps in MySQL going to be sometime in 2021 since it can't make it all the way to 9999999999?
Answer:
- 2147483647 is 2038 (not 9999999999) so there is no problem.
unsignedisn't needed since 2147483647 fits fine in a signed MySQL int.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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。Standard UNIX timestamps are a signed 32bit integer, which in MySQL is a regular "int" column. There's no way you could store 9,999,999,999, as that's way outside the representation range - the highest a 32bit int of any sort can go is 4,294,967,295. The highest a signed 32bit in goes is 2,147,483,647.
If/when UNIX timestamps go to a 64bit data type, then you'll have to use a MySQL "bigint" to store them.
As for
int(10), the(10)portion is merely for display purposes. MySQL will still use a full 32bit internally to store the number, but only display 10 whenever you do a select on the table.