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

Question

由于统计原因,我有一个包含数百万次写入的日志记录表.所有列都是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？

回答:

Answer 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.

只有你不需要处理未来的价值观.考虑一家银行正在处理30年期抵押贷款报价.这使抵押贷款的结束在2040年,超过了2038年的限制.如果/当64位开关发生时,那么我们将遇到y292,277,026,596k问题.但如果有人想安排我到处修理它,我很乐意帮忙. (20认同)
我很高兴你肯定我所说的,但是这对于存储日期意味着什么呢？ (3认同)
这意味着你不能以大于2 ^ 31-1的方式存储日期(那是2147483647,它可以表示直到2038年的时间.9,999,999,999会让你到2287左右).这是一个已知问题; http://stackoverflow.com/questions/36239/what-should-we-do-to-prepare-for-2038 (2认同)