慎用自增ID作为排序依据

背景

目前公司有一些MYSQL大表,具有分库的潜在需求,也就是按照业务某维度拆分到多台物理Mysql实例上,从而实现横向扩展。

因为每一条记录需要一个唯一ID标识,而在分库情况下无法再使用MYSQL自增ID保障全局ID唯一性,所以我开发了一个分布式ID生成服务。

问题

评论表是一个大表,此前业务上是基于MYSQL自增ID做排序的,也就是认为ID大的是后发的评论。

然而仔细想一下,是不是这样呢?

其实从你收到评论请求,到评论入库分配得到一个自增ID,这个过程本身就是并发的耗时的,很有可能一个先发评论因为处理慢而后入库,得到一个较大的ID。

所以,问题的本质错误在于:用自增ID做为业务排序依据是一个未经思索的实现,是有提升空间的。

当我提出评论分库的建议时,会发现分布式ID生成服务也并不能提供一个严格自增的ID(仅仅是趋势递增,不重复),这种情况下我们认为评论基于ID完成业务排序就基本不可行了。

结论

永远不要依赖ID作为业务的排序依据,因为入库本身就是并发的,用ID作为依据是不准确的,同时分库后分布式ID算法是很难保障严格递增的。

更好的解法应该是建立类似create_time、update_time的字段,这样才是符合业务的排序依据,扩展性才更好。

发表评论

电子邮件地址不会被公开。