我的问题是关于自然键和auto_increment整数为主键。
例如，我有表A、B和A_B_relation。A和B可能是某个对象，A_B_realtion记录了A和B的多对多关系。
A和B都有自己的全局唯一id，如UUID。UUID对用户可用，这意味着用户可以通过UUID查询A或B。
有两种方法可以设计表的主键。- 使用auto_increment整数。
A_B_relation引用整型为FK - 使用UUID。
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`.
所以我认为后一种情况更方便。这样对吗?后一种情况的不足是什么?
根据我的意见，使用自然键或自动递增键的便利性取决于您提供的程序解决方案。这两种方法各有利弊。因此，最好的解决方案是正确理解这两种键类型，分析您要提供的业务解决方案类型，并选择适当的主键类型。
自然键是一个列或一组列，可以用来唯一地标识表中的一条记录。这些列包含与表中其他列有关系的真实数据。
自动递增键，也称为代理键是一个单表列，它包含唯一的数字值，可以用来唯一地标识表中的单行数据。这些值是在运行时将记录插入表时生成的，并且与该行的其余数据没有关系。
使用自然键的主要优点是它有自己的含义，并且需要较少的与其他表的连接，就像我们使用代理键一样，我们需要连接到外键表才能获得使用自然键得到的结果。
但是，假设我们不能从单个表中获得所需的所有数据，并且必须与另一个表连接才能获得所需的所有数据。然后，使用代理键代替自然键是很方便的，因为大多数情况下，自然键是字符串，并且比代理键的大小更大，并且使用更大的值连接表将花费更多的时间。
自然的琴键有它自己的含义。因此，在搜索记录时，使用自然键比使用代理键更有利。但是随着时间的推移，我们的程序逻辑发生了变化，我们必须改变自然键值。这将是困难的，并将导致所有外键关系的级联效应。我们可以使用代理键来克服这个问题。由于代理键与一行的其他值没有关系，因此逻辑的更改不会对代理键产生影响。
同样，我看到使用代理键或自然键的便利和不便完全取决于您提供的解决方案。