解决方法:在商品表增加一个更新时间(默认为发布时间),商品表改为更新时间排序;卖家每天可以去更新一次这个时间。
疑问:更新时间这个字段是直接用datetime类型,还是使用MySQL里面时间存储方法int(1970-01-01到当前的秒数);这两个查询效率哪个高?操作方法哪个方便?或者还有没有其它有效的方法?
10 个解决方案
#1
从处理速度来说,int更快,不过如果你展示的时候需要频繁convert成正规的日期格式,那就要权衡了
#2
仅仅是检索数据的话,如果索引建好了,datetime和int类型的应该是速度差不多的,几乎可以说一样。但是考虑到后期查数据还是要转换成datetime ,而且datetime方便,建议用datetime把。这个列上的索引要建好。
#3
datetime就是用16进制数存的,效率没问题。你要解决的是排行榜的锁问题。
#4
DateTime本身就是数字型,只是表示格式而已
#5
虽然是datetime类型,但其实内部存储的就是 1970-01-01到当前的秒数 ,所以直接按照datetime字段排序 就行了哈
#6
我一般把时间日期什么的都定义成vchar类型,省心
#7
建议用datetime类型,然后在该字段上建立索引
#8
赞同,在存储端是没啥太大差别的。lz主要是要解决读的问题。千万级数据可以考虑使用分区表。
#9
可以使用DATETIME2 类型。。。
#10
如果仅仅是读取的话建议使用int,效率较高
#1
从处理速度来说,int更快,不过如果你展示的时候需要频繁convert成正规的日期格式,那就要权衡了
#2
仅仅是检索数据的话,如果索引建好了,datetime和int类型的应该是速度差不多的,几乎可以说一样。但是考虑到后期查数据还是要转换成datetime ,而且datetime方便,建议用datetime把。这个列上的索引要建好。
#3
datetime就是用16进制数存的,效率没问题。你要解决的是排行榜的锁问题。
#4
DateTime本身就是数字型,只是表示格式而已
#5
虽然是datetime类型,但其实内部存储的就是 1970-01-01到当前的秒数 ,所以直接按照datetime字段排序 就行了哈
#6
我一般把时间日期什么的都定义成vchar类型,省心
#7
建议用datetime类型,然后在该字段上建立索引
#8
赞同,在存储端是没啥太大差别的。lz主要是要解决读的问题。千万级数据可以考虑使用分区表。
#9
可以使用DATETIME2 类型。。。
#10
如果仅仅是读取的话建议使用int,效率较高