长 LONG 型储存时间的意义是什么？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2867 天前的主题，其中的信息可能已经有所发展或是发生改变。

见到有些程序用长整型数据存储时间，中间实现需要数据的转化，特意转化成长整型，出库时又要转换一次，这么做的目的是什么？有效率还是其它优势 /方便？

长整型

转化

有效率

Long

28 条回复 • 2017-01-04 22:55:32 +08:00

2017-01-03 20:17:57 +08:00 via iPhone

你说的是 timestamp ？

rainex

2017-01-03 20:19:59 +08:00

没看懂你到底问的是什么，只能说
1 部分数据库，用数字类型的字段存储时间戳，比用日期型的字段， sql 性能好一些
2 多年没看过 php 了，记得好像是没 long 类型，只有 float 类型？ 32 位 php 的 int 存储当前时间的毫秒位数不够，有诸如此类的问题。
3 也有可能是部分码神瞎胡写

weyou

2017-01-03 20:31:01 +08:00 via Android

是说用 int64 来表示时间么？

smilezino

2017-01-03 20:37:46 +08:00

时间戳无关于时区

loggerhead

2017-01-03 20:43:28 +08:00

1. 没有歧义
2. 省空间
3. 某些情况下进行运算的时候省时间

murmur

2017-01-03 20:43:47 +08:00

因为有的时候你的却搞不懂每个数据库的 datetime 倒是是个什么玩意儿有的是 date 有的是 string
long 的话你能搞清楚
而且比较大小、做差的时候 long 更简单一点点

jarlyyn

2017-01-03 20:51:03 +08:00

问题是用数字还是长整？

kimwang

2017-01-03 20:51:32 +08:00

不好意思，我在自学 PHP ，概念说得不准确，已在物色合适的图书购买。

说回问题，其实 ip2long 和这种将时间转化为 INT(11)的格式存入数据库，它的作用是什么？如果要进行输出或者对比不是更麻烦？ MYSQL 本身就有时间型，为什么他们不用呢?

为了描述问题，我放了两张图片，谢谢。

数据类型设置情况：
http://i1.piimg.com/4851/47e0d51ff5a1d1d5.png

转化后保存到数据库的情况：
http://i1.piimg.com/4851/04518dff3e52fa6d.png

kimwang

2017-01-03 20:54:19 +08:00

@jarlyyn

你好
用的:
INT 或 INTEGER 4 字节 (-2 147 483 648 ， 2 147 483 647) (0 ， 4 294 967 295) 大整数值

保存后的情况请看 8 楼的第二张图片。

Troevil

2017-01-03 20:55:50 +08:00

@kimwang 抛开需求看问题通常都是没有结论的, 这个设计直接问这个项目的设计者不就好了, 无论是时间戳还是 datetime 都是各有利弊的, 三个字 `看需求`

kimwang

2017-01-03 20:56:51 +08:00

@RE @smilezino 我描述得不够好让你误会，不是时间戳的问题，请看 8 楼补充。

kimwang

2017-01-03 20:58:05 +08:00

@weyou 是的，大概是这意思，我当时浏览的程序用了 MYSQL 大整数值（数据类型）_int(11)

2017-01-03 21:10:05 +08:00

@kimwang

你这截图就是时间戳啊，估计你看的教程也不准确，
1. 存储时间戳只需要 10 位不需要 11 位，
2. 因为时间没有负数形式（准确的说是 1970 年 1 月 1 日到现在不存在负数）所以勾选 unsigned 这样可以得到更大的最大值。

时间戳（ timestamp ）指的是 1970 年 1 月 1 日开始到某个时间点的秒数，不记录时区等信息。数据量庞大的情况下，如果需要计算一些时间差、时间范围等，数字形式比日期形式更好直接计算。

估计是你用的 mysql 编辑器自动把 int 加上了逗号分隔，让你有了疑惑（这点是结合你之前的帖子猜测的）。

zhidian

2017-01-03 21:12:04 +08:00

因为从一开始，时间就是整形，那叫 Unix Time 或者说 Epoch Time （创世纪？）。但是 unix time 用的 int32 ，精度不够（精确到 s ），后来大家都觉得应该用毫秒啊！于是换了 int_64 来存，记得以前自己算过，按照毫秒够用几百万世纪。（当时我的疑问是“为什么要用 signed ，少了一半的可用区间啊？！”）

zhidian

2017-01-03 21:15:27 +08:00

外，转化为整形对比更简单啊。直接做差，然后用 / 和 % 就可以算出每个时间精度的量。

murmur

2017-01-03 21:17:45 +08:00

@jarlyyn mysql 里的普通 int 不够要用 big int 级别的大整和长整。。翻译问题吧

lizon

2017-01-03 21:19:57 +08:00

你精度只到秒，目前来看 int32 是够的，到毫秒不够

qiayue

2017-01-03 21:20:19 +08:00

不同的需求，用不同的存储格式，比如我要找出距今 2 小时内的所有记录，是不是用整形记录的时间（时间戳）更方便

kimwang

2017-01-03 21:22:27 +08:00

@RE
估计是你用的 mysql 编辑器自动把 int 加上了逗号分隔，让你有了疑惑（这点是结合你之前的帖子猜测的）。
RE:对，可能有这个情况，因为数据库内逢千位打逗号我一时间没缓过来，以为搞财务呢。

我查到了
http://www.cnblogs.com/thingk/p/3826751.html
是时间戳的问题，谢谢。