ORDER BY，13位数时间，储存成INT快，还是其他时间格式快？解决思路

2012-03-16

ORDER BY，13位数时间，储存成INT快，还是其他时间格式快？有1千万条记录，有一列记录由13位数字组成，13位数的

ORDER BY，13位数时间，储存成INT快，还是其他时间格式快？
有1千万条记录，有一列记录由13位数字组成，13位数的时间（单位：微秒，如：1355752000000）。这列数字在搜索时，用作 ORDER BY 使用。
请问，在储存过程中，储存成INT？还是其他时间格式？用于搜索时速度更快？谢谢。

[解决办法]
用int 来存储吧，其实2者差距应该不大，用时间存储的话可以很直观的展现，用int 可以省点空间。
[解决办法]
长整型比较快。
[解决办法]
bigint
[解决办法]
BIGINT 8字节最大9223372036854775807
INT 4字节最大 2147483647 （显然无法满足你的 "一列记录由13位数字组成，13位数的时间")

所以要用长整型，也就是BIGINT.

INT（13）后的这个13对你来说没有意义

引用
MySQL还支持选择在该类型关键字后面的括号内指定整数值的显示宽度(例如，INT(4))。该可选显示宽度规定用于显示宽度小于指定的列宽度的值时从左侧填满宽度。

显示宽度并不限制可以在列内保存的值的范围，也不限制超过列的指定宽度的值的显示。

当结合可选扩展属性ZEROFILL使用时，默认补充的空格用零代替。例如，对于声明为INT(5) ZEROFILL的列，值4检索为00004。请注意如果在整数列保存超过显示宽度的一个值，当MySQL为复杂联接生成临时表时会遇到问题，因为在这些情况下MySQL相信数据适合原列宽度。

[解决办法]
int比datetime快。
[解决办法]
int 再加个索引
[解决办法]

引用原来如此，那后面的13，不是指如果插入数值为14位数时，会报错，或只能插入前13位数，第14位数被忽略？

热点排行

Mysql

ORDER BY，13位数时间，储存成INT快，还是其他时间格式快？解决思路