我的问题是关于自然键和auto_increment整数作为主键。
例如，我有表A，B和A_B_relation。 A和B可能是某个对象，并且A_B_realtion记录A和B的多对多关系。
A和B都有自己的全局唯一ID，例如UUID。 UUID对用户可用，这意味着用户可以通过UUID查询A或B。
有两种方法可以设计表的主键。
A_B_relation将整数引用为FK。 A_B_relation将UUID引用为FK。 例如，用户想通过A的UUID查询与A相关的所有B信息。
对于第一种情况，查询流程是这样的:
First, query A's integer primary key by UUID from `A`.
And then, query all the B's integer primary key from `A_B_relation`.
At last, query all the B's info from `B`.
对于后一种情况，流程如下:
Query all the B's UUID from the `A_B_relation` by A's UUID.
Query all the B's info from `B`.
所以我认为，后一种情况更为方便。这是正确的吗？后一种情况有什么不足？
最佳答案
根据我的意见，使用自动增量键的自然键的方便性取决于您提供的程序解决方案。两种方法各有利弊。因此，最好的解决方案是正确理解这两种 key 类型，分析您要提供的业务解决方案类型，然后选择适当的主 key 类型。
自然键是一列或一组列，可用于唯一标识表中的记录。这些列包含实际数据，该数据与表的其余列有关系。
自动递增键，也称为替代键是一个单表列，其中包含可用于唯一标识表中数据的唯一数值。将记录插入表时，会在运行时生成这些值，并且这些值与该行的其余数据没有任何关系。
使用自然键的主要优点是它具有自己的含义，并且需要与其他表的联接较少，就好像我们使用代理键一样，我们将需要联接到外键表以获取通过自然键得到的结果。
但是要说我们不能从单个表中获取所有必需的数据，而必须与另一个表连接以获取所有必需的数据。然后，使用代理键代替自然键会很方便，因为大多数时候，自然键是字符串，并且比代理键的大小大，并且使用较大的值连接表将花费更多时间。
自然键具有其自身的含义。因此，在搜索记录时，使用自然键优于代理键更为有利。但是要说，随着时间的流逝，我们的程序逻辑会发生变化，因此我们必须更改自然键值。这将很困难，并且将在所有外键关系上造成级联效应。我们可以使用代理键来克服此问题。由于代理键与行的其余值没有关系，因此逻辑更改不会对代理键产生影响。
同样，正如我所见，完全基于您提供的解决方案使用代理键或自然键会带来便利和不便。