Mysql 在我的情况下，将两个ID列作为一个来索引另一个以引用少数表是否更好？

在我工作的当前数据库中，很少有表，有两个以上的ID列，一个是自动递增的，用于索引另一个唯一的ID列，其中ID由程序员生成并存储，用于索引。 我以前从未见过这样的情景。他们这样做的原因是，当他们合并在一个db服务器上生成的数据时，可以轻松地与另一个数据库合并，而不会产生冲突。因为他们之间几乎没有什么关系

如果使用单个自动递增ID

• 记录组将插入到具有相同属性的主表中 id引用了它的外部表。如果此数据合并到另一个 已存在某些数据的数据库，它们可能与 该数据库中自动生成的ID

• e、 g.TBL_1是其他10个表中提及的主表，因此 当倾倒到另一个容器中时，必须保留TBL_1中规定的id DB。可能已经存在一些具有相同ID的记录。然后 冲突由此产生

• 或者，如果将增量过程留给新的DB，则 引用的表将与此表失去完整性

这是正确的使用方式吗？（这是一个已经存在的系统，不是我创建的）

---

感谢您的支持。

我看不到自动增量列有任何好处。根据我对您问题的理解，所有引用都是使用显式生成的ID完成的。我相信，出于这个原因，在应用程序级别显式生成ID是完全有效的，但我会让这些生成的ID成为唯一的ID，以使系统更简单、更容易理解。它将防止将来的修改意外地使用错误的ID，即在合并到另一个数据库后无法生存的ID。

没有魔法：

• 或者，您需要使用全局唯一标识符（例如GUID或某种全局可见的“ID服务器”），以避免不同数据库之间发生冲突
• 或者，您需要将ID从一个“名称空间”转换为另一个，递归地包括所有外键

顺便说一句，虽然GUID确实会将所有行抛出，但自动递增实际上会有类似的效果（只是更依赖于插入的时间）。不要忘记，聚集表中的二级索引非常昂贵（它需要包含PK的一个副本，并且可能导致双重查找）

---

除非您有自动递增ID的特定原因（例如保持子FKs苗条），否则只需使用应用程序生成的ID作为PK。如果您使其具有全局唯一性，那么将避免任何ID转换的需要，并大大简化合并过程…

这不是真的。您有第三个选项，它是一个由auto_increment和integer列组成的复合键，用于定义服务器/mysql的位置（任意整数）。即使您在不复制的情况下将所有数据合并在一起，也会保持完整性，一切都会正常工作。主键是定义为PK（auto_increment，GUID）还是仅定义为主键的auto_increment部分？