为什么不能使用关系型数据库中自增长的ID，进行查询，修改，或者删除呢，有人说分库分表的时候很麻烦，请帮我详细解答一下。

Question

为什么不能使用关系型数据库中自增长的ID，进行查询，修改，或者删除呢，有人说分库分表的时候很麻烦，请帮我详细解答一下，谢谢了。

Answer 1

你这不算一个问题啊，或者，你把几个问题搞混了。

第一个，使用主键，进行删除改查，可以吗？

当然没问题，并且绝大部分场景都是这样的。

第二个，主键类型是自增长 ID ，在分库分表时会很麻烦，不要使用它，为什么？

在 MySQL 这种功能很弱的数据库的默认情况下 ，它的“自增长 ID”仅仅能设置点“初始值，步进”这些项，如果你再自己动手实现分库分表，那么这个 ID 的值的维护成本很大。

比如，最开始，你作 2 个分表，那么这个自增长 ID 的步进设置为 2 ：

• 第一个表，它的 ID 可以是： 1,3,5,7,9

• 第二个表，它的 ID 可以是：2,4,6,8

这样看起来没问题，但是，如果在中途你又要加 2 个分表，你的 ID 怎么做？就算你改变规则，把这事搞定了，那接下来的一个问题，就是当你看到一个 ID 值时，你怎么判断它在哪个表中？

第三个问题，分库分表时， 主键怎么处理？

首先，分库分表，我们一般考虑的是 Hash 键，它不一定要用表的主键，但是，很多时候直接就拿主键来用了。

其次，“自增”这东西，只是现象，不是实现方式。正常点的关系数据库（Postgresql，Oracle之类的），都有 sequence ，序列这个机制，“自增”只是帮你定义了一个 sequence ，每次取值都从序列当中取一个，值是什么，就是序列怎么实现的事了。 MySQL 没有序列，问题就麻烦了。

在有序列机制的情况下，分表根本不是事，当要让多表使用同一个序列就可以了，对吧。

分库的话，就一定需要引入外部的“序列生成器”了。

Hash 键的处理是分库分表的基础，不是一个用不用自增 ID 这么简单的一个点的了。而且，一个专门的解决方案，暴露给使用者的，主键上其实也是“自增 ID”，只是它这个的“序列生成器”肯定不是系统默认自带的那套了嘛。

Answer 2

如果是分库或者分表，所有主键id都用自增，那么在查询记录时同一张表会有同样id的记录【比如user分成user1和user2两个表，两个表中都有id为1的记录】，这是不可以的，所以都有一套主键生成算法，不管是分库还是分表，同一个表里的主键不会重复。