如果查询时没有在任何地方使用自动递增主键，那么表中的自动递增主键有什么用。
例如，我有一个表单，用户在其中注册自己的userid/passwd等，并填充如下表。
user table
id int auto increment primary key
userid unique key
passwd varchar
etc
etc
每当我检查登录用户或任何其他查询时，我总是使用select * from tbname where userid = ?我有一个唯一的索引，那么在id列上有主索引有什么用？
速度也会有差别吗？
编辑：我的用户ID实际上是一个用户名选择我的注册用户。
我在mysql和sqlserver下标记了这个问题，因为它可能同时属于这两者。
自动递增和键(主键或唯一键)是两种不同的东西。
关键类型之间的区别是：
主键：
- 每个表中只有一个
- 不允许为null
- 主键是唯一的密钥标识符
唯一密钥：
- 表中可以有许多唯一的键
- 允许为null
自动增量加在一起是另一回事。
如果在列中选择自动递增，则在插入记录时不会提供值。数据库将跟踪上次插入的递增ID，下一次插入将使用之后的值(按指定的数量递增，最常见的是1)
您的问题更多地是关于数据库设计，而不是特定的DBMS。您感到困惑，因为混合了代理密钥和 自然密钥代理密钥 很好，因为它没有真正的意义——它只用于行识别。这是一种最常见的设计，因为您的数据集可能没有其他识别条件，或者它们不可靠。您的 自然键 在某些特定情况下，表可能具有自然键，即某些属性或属性集可以用作代理键，即标识表中的一行。若是这样的话，那个么您可以考虑将自然键作为表中的主键。 什么更好 如果你的 将您的 如果公约对有帮助，那么它们就是好的id似乎就是代理密钥。userid列有某种生成算法，那么它显然不能自动递增，它会有自然键的感觉。如果您确信该键始终是唯一的，那么您的id列是多余的，那么维护列是没有意义的，因为它的唯一角色(即行标识)已经由另一列维护。事实上没有什么不好的，主键列不会自动递增(这里，我再次假设userid有一些生成算法)。id视为某种约定——因为是您来决定——要么您需要特殊的行标识列，要么您不需要。但是，如果userid没有特殊的生成算法，那么id就更加多余了。在这种情况下，您可以删除id并将userid定义为自动增量。作为结论-记住
代孕主键通常是开发人员的首选，因为它们不受小的生活变化的影响。例如，有一天你可能会决定让用户更改他们的id，然后如果你有其他表通过userid引用这个表，你就有非零的机会把事情搞砸。有了代理密钥，它需要以任何方式更改的可能性都为零。它只是使用起来更安全。
但我还想提到，除了主键、唯一键、自动递增键、自然键和代理键之外，还有一个问题是聚集索引与非聚集索引。聚集索引是用于物理存储表行的索引。因此，它提供了最快的访问速度。对于许多初学者来说，主键是否必须是聚类索引并不明显。如果你知道90%的时间你将在查询中使用userid，并且想利用它，但不能保证userid永远不会为null(或更改)，那么就让代理id成为你的主要非聚集键，让userid成为你的自然唯一聚集索引。
在这种情况下没有任何用处。在正常的表设计中，您将使用user_id的自动增量来生成一个唯一的主键。如果您放弃了自动递增ID列，则可以为自己节省一些索引空间。您应该将user_id设置为primary以避免null。
自动递增是自动生成行id，不会重复。这是一种生成唯一用户id的有用方法。然而，拥有它并不能保证唯一性，因为如果没有唯一限制，您可以返回并编辑值