背景

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

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

问题

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

然而仔细想一下，是不是这样呢？

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

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

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

结论

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

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

如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~