在您的数据库表中，使用非连续的id作为主键是否可行？

Question

我对数据库不太了解，无法找到正确的词语来提出问题，所以让我通过一个例子来解释我的意图：假设我想要将表的主键设置为从API获取的ID，但大多数API请求都会返回404错误。因此，我的表将如下所示：

我也不知道如何在Stack Overflow上格式化类似表格的结构，所以这将是一个粗略的视觉效果：

API_ID_PK | name
------------------
1         | Billy
5         | Timmy
23        | Richard
54        | Jobert
104       | Broccoli

ID号码是否需要严格按照1个数字进行顺序分隔？还是可以有所不同？以下是需要执行的内容：

ID PK |  API_ID   | NAME
----------------------------------------
1     |    1      | Billy
2     |    5      | Timmy
3     |    23     | Richard
4     |    54     | Jobert
5     |    104    | Broccoli

第二个表是否更高效的索引原因？还是第一个表完全可以？谢谢！

- tobogganjester

---

是的，我非常确定ID会自动递增一。 - Caffeinated

@Coffee：ID默认情况下仅自动递增1。但是这可以更改。请参见我的答案。 - Ayush

@tobogganjester：不应该有影响。对于数据库而言，你可能已经拥有了所有连续的数据，但删除了2...4、6...22、24...53等部分。（尽管如果有来自另一个数据库的主键，你可以放心地创建自己的主键，然后将其指定为“tmdb_id”列。） - Brad Christie

Answer 1

不会对效率产生影响，即使您的ID不连续。事实上，MySQL（和其他数据库）允许您设置变量auto_increment_increment，使ID增加超过1。这在多主设置中常用。

- Ayush

---

如果这是一个任意序列呢？上面的OP ID没有任何模式，只是随机的。 - Caffeinated

无所谓，ID 的唯一要求是它们必须是唯一的。 - TMN

通常使用ID创建某种二叉树。因此，正如TMN所说，唯一的要求是它们必须是唯一的。 - Ayush

Answer 2

如果ID不是连续的，也是可以的。在处理企业软件时，我经常使用GUID作为ID，因为多个业务可能共享同一个对象，而它们永远不会是连续的。

需要注意的是，如果数字相同，你存储的ID值是由什么决定的？

- Paurian

---

我正在从Themoviedb中导出电影数据，因此每个tmdb id都是唯一的，但其中很多会被tmdb删除，并且他们的政策是保持该ID未使用。我只是担心如果它不是1 2 3 4 5等等，那么效率会受到影响。 - tobogganjester

听起来你没问题。像你所经历的ID映射是很常见的。你需要处理他们API抛出的情况，例如如果他们返回按最后修改日期排序的列表（这可能会在连续调用中向您返回相同的记录）。MySQL使用“on duplicate key update”来处理此问题。祝你好运！ - Paurian

使用非连续的 UUID 作为主键会影响插入性能吗？原因是主键是聚集索引。 - undefined

Answer 3

如果您在ID列上有一个聚集索引（Sql-Server），并插入具有随机值的ID（例如GUID），则这可能会产生负面影响，因为聚集索引的物理顺序对应于逻辑顺序。这可能导致大量索引重新组织。请参见：Improving performance of cluster index GUID primary key。

然而，有序但不连续的值（值之间没有被1分隔）对于聚集索引不是问题。

对于非聚集索引，顺序并不重要。只要它们是唯一的，插入主键的随机值就可以了。

- Olivier Jacot-Descombes