什么时候应该将一列标记为主键？

Question

我有一张这样的表：

// cookies
+----+---------+-------------------+------------+
| id | user_id |       token       |   expire   |
+----+---------+-------------------+------------+
| 1  | 32423   | dki3j4rf9u3e40... | 1467586386 |
| 2  | 65734   | erhj5473fv34gv... | 1467586521 |
| 3  | 21432   | 8u34ijf34t43gf... | 1467586640 |
+----+---------+-------------------+------------+

这几天我想了想。我想我不需要id列。目前id列是 PK，而且我在token列上有一个唯一索引，以使其快速搜索。

现在我想知道，我可以删除id列并将token列作为PK吗？这是正常的吗？

老实说，我从来没有创建过没有id列的表（它一直是 PK），所以选择token列作为 PK对我来说很奇怪。

Answer 1

这取决于很多事情。假设您使用的是 innodb，它的价格会很高。因此，您需要评估和平衡用例的利弊。

大 varchar 列的缺点：

• 由于令牌的随机顺序
  • 你的插入会明显变慢，
  • 会造成大规模的碎片化和
  • 更频繁的页面拆分
• 由于这种碎片，表实际上会使用更多的空间，而不是省略您正在使用的 4 或 8 字节整数键所节省的空间。
• 如果您有任何其他键，它们将在最后包含这个大主键，从而进一步膨胀您的表：https : //www.percona.com/blog/2006/10/03/long-primary-key-for-innodb -表/

自然主键的优点：

• 由于 InnoDB 主键查找的性质非常快，因此如果您仅通过此列查询您的表，这可能会给您带来一些优势（尽管自适应哈希索引对辅助键查找有很大帮助）

大多数时候，出于空间考虑，人们试图使用自然键来消除 id 列，这与实际发生的情况正好相反。如果您希望将其用于查询优化并且其弊大于利，那么就去做吧。

Answer 2

如果表有自然的主键不会改变，那么用它作为PK是合适的

如果有时很长，您可能会使用 ID 作为性能的 PK

正如 Nagy 的回答中详细介绍的那样。因为它是乱序的，所以它会碎裂。唯一索引也会碎片化。

如果您使用自然键，则 FK 会更长。但是现在在查询中，您不必重新连接到该表来获取自然键。