分表分库后的id分配问题

分表分库一般是你的业务并发高，或者数据量大的情况下进行业务拆分。但是分表后会带来一系列你想不到的问题，比如我们今天要讨论的分表分库后的 id 分配问题。

分表之前，你的数据表中的主键，可以设置为自动增长等。但是分表后，id 在所有分后的表中是不能重复的。举个例子，我的用户表，我一共分了 3 个表。那么 u1 中存在 id 为 1 的主键后，u2、u3 就不能使用相同的主键 id 了。因此，分表后，要达到每个表中的主键不能相同，而且效率还得得到保证。

这里我推荐几种做法，供大家参考。

1、每个表还是保持各自的自动增长，但要让它们增长的不一样。

具体做法就是，每个表配置不同的起始值。比如，u1 配置 auto_increment = 1，然后步长为 3。u2 配置起始值为 2，步长也为 3，u3 配置起始值为 3，步长也为 3。这样做了之后，主键 Id 都能够自动增长，且能够做到不重复。

2、借助 UUID、Mongo 的 ObjectId 等生成唯一主键 Id。

UUID 由于每个微服务系统生成的都不一样，因此可以考虑作为分表后的主键 Id 来使用。另外 Mongo 的 ObjectId 本身也是采用的 UUID，因此也可以用来做分表后的主键。但是，这两个的规律性都比较差。

3、借助开源的分布式 ID 生成器。

这类开源的 ID 生成器就比较多了，我前面也写过类似的文章《5 大分布式 ID 生成器优缺点简单对比》，还被不少人转载过。

比如，出名的 snowflake，它产生的 id 太长。但是效率非常的高，适合超高并发场景。

其他的如：Leaf、sharding-jdbc、uid-generator 都需要借助 DB 支持，也就是说需要另外的表来支持。

以上就是分表分库后，全局 ID 的生成策略。我这里讨论的比较简单，具体结合自己公司的业务进行调整或采用其他方案。

： » 分表分库后的id分配问题