Mysql pk是否作为绝对id有效？（Django）

删除最后一个模型后，将创建的下一个模型将被分配已删除模型主键，这意味着指向已删除模型的任何链接现在都将指向新模型

那么我们应该使用PK还是创建UUID呢？ e、 g用户配置文件，一些高级配置文件在删除时会指向一些全新的配置文件

• 这个网站，stack overflow使用PK提问，我想知道我写的东西是否也适用于这里

---

从最简单的意义上讲，数据库对PK字段使用计数器，并在添加新记录时将其递增。删除/更新操作不会修改计数器。因此，db不可能两次使用相同的值

编辑：哦，这似乎是Sqlite的一个特性。详情如下:

引用文件：

如果在insert上未指定ROWID，或者如果指定的ROWID 如果值为NULL，则会自动创建相应的ROWID。 通常的算法是给新创建的行一个ROWID，该ROWID是 比插入前表中最大的ROWID大一个

以及：

上面描述的正常ROWID选择算法将生成 只要不使用 最大ROWID值，并且您永远不会使用 最大的罗维德

---

事实上，您可以从中了解到，在主键上创建

AUTOINCREMENT

可以阻止这种麻烦

尝试：

---

“删除最后一个模型后，将创建的下一个模型将被分配删除的模型主键”您确定吗？你测试过了吗？如果是，您使用的数据库是什么？至少Postgres不会有这种行为，它会不断增加ID，不管删除了什么。我不确定其他数据库后端。我测试了几次，本地主机Django sqlite，可能在生产中使用了它想要的MySql，我会检查，谢谢。当在本地测试时，使用-'Django.DB.backends.sqlite3'作为数据库，它确实为新模型使用了一个已删除的pk。在生产环境中，或者至少在使用MySql时，PK会按预期增加，并且始终是唯一的

CREATE TABLE "Pity" (
"ID" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL);