即使您的用户名是唯一的，使用额外的id列而不是使用varchar作为主键也没有什么好处。

• 有些人更喜欢使用整数列作为主键，作为永远不需要更改的代理键，即使其他列可能会更改。虽然没有什么可以阻止自然主键也可以更改，但您必须使用级联外键约束来确保相关表中的外键与任何此类更改同步更新。
• 主键是32位整数而不是varchar可以节省空间。在引用用户表的每个其他表中选择int或varchar外键列可能是一个很好的理由。
• 如果在索引的末尾添加新行，与将它们楔入索引的中间相比，插入主键索引会更有效一些。MySQL表中的索引通常是B+Tree数据结构，您可以研究这些结构以了解它们的性能。
• 一些应用程序框架更喜欢这样的约定，即数据库中的每个表都有一个主键列id，而不是使用自然键或复合键。遵循这样的约定可以简化某些编程任务。

这些问题都不是交易破坏者。使用自然键也有好处：

• 如果按用户名查找行的频率高于按id搜索行的频率，则最好选择用户名作为主键，并利用InnoDB的索引组织存储。如果可能，将主键查找列设置为主键，因为主键查找在InnoDB中更有效（您应该在MySQL中使用InnoDB）。
• 正如您所注意到的，如果您已经对用户名有了唯一的限制，那么保留一个不需要的额外id列似乎是浪费存储空间。
• 使用自然键意味着外键包含一个人类可读的值，而不是任意的整数id。这允许查询使用外键值，而不必返回父表以获取“真实”值。

问题是，没有一条规则涵盖100%的案例。我经常建议您保持选项的开放性，甚至在单个数据库中也使用自然键、复合键和代理键。
我在我的书SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming中的“需要ID”一章中介绍了代理键的一些问题。

这个标识符被称为Surrogate Key。我链接的页面列出了优点和缺点。
在实践中，我发现它们是有利的，因为即使是超级密钥数据也会随着时间的推移而改变（即用户的电子邮件地址可能会改变，因此任何对应的关系都必须改变），但代理密钥永远不需要改变它所标识的数据，因为它的值对关系没有意义。
从JOIN的Angular 来看，它也很好，因为它可以是一个密钥长度小于varchar的整数。
我可以说，在实践中，我更喜欢使用它们。由于在开发过程中不断变化的需求，多列主键或跨表使用的数据代表性超键必须在以后变得不唯一，这让我被咬了太多次，而这不是你想处理的情况。

在我看来，每个表都应该有一个唯一的、自动递增的id。
以下是一些实际原因。如果有重复的行，则可以轻松确定要删除的行。如果你想知道行被插入的顺序，你可以在id中找到这些信息。id为外部引用提供密钥。
最后，任何可能描述用户的东西——姓名、地址、电话号码、电子邮件地址——都可能随着时间而改变。

我是mysql。

1:Index fields 2:Unique fields and 3:PK fields.
index means pointable
unique means in a table must be one in all rows.
PK = index + unique

在一个表中，您可能有许多独特的字段，如
用户名或护照代码或电子邮件。
但是你需要一个像ID这样的字段，它是唯一的并且是索引（＝PK）。第一个总是一件事，永远不会改变，第二个是唯一的，第三个是简单的（因为通常是数字）。

使用数字id的一个原因是，在其上创建索引比在文本字段上创建索引更简洁，从而减少了查找特定用户所需的索引大小和处理时间。另外，当交叉引用不同表中的用户（关系数据库）时，要保存的字节更少。