以下是使用现有的唯一列作为主键而不是仅为此目的添加特殊列的注意事项列表：

• 唯一列必须不可为空。
• 独特的柱应该是便宜的。（例如整数，而不是字符串，特别是不是复合键。这是性能问题。）
• 唯一列的值在行的整个生存期内应永远不会更改。（即使你的RDBMS允许你改变主键的值，在实践中，强烈建议你避免这样做。
• 在数据库模式的未来修订中，不太可能将唯一列重构为其他内容（尤其是不重构为非唯一列）。
• 理想情况下，唯一列应该是一个按顺序递增的数字，以便可以使用聚集索引。（这是性能问题。）

我写的3个表中有2个是“自然的”PRIMARY KEY。我避免人为地将id添加到这样的表中。
以下是一些常见的模式。（id是AUTO_INCREMENT`）

• uuid是非常随机的，因此这可能是最佳的：

PRIMARY KEY (id),
  UNIQUE(uuid)

• 对于foo和bar之间的many-to-mapping表，这可以节省空间和速度，同时确保不会意外插入重复项。它被实现（在InnoDB中）为两个2列BTrees：

PRIMARY KEY(foo_id, bar_id),  -- for mapping one way
  INDEX(bar_id, foo_id)         -- for mapping the other way

• 有时人工id是有益的，但这可以让你使用PK“引用的局部性”：

PRIMARY KEY(user_id, id),  -- cluster together all the users stuff
  INDEX(id)    -- sufficient to heep AUTO_INCREMENT happy

至于你的具体问题：

• PK中列的数据类型是次要的。最大的问题是需要触摸多少行。
• 在对多列进行测试时，复合（多列）索引通常优于两个单独的列，而不管基数如何。
• TEXT和BLOB不能被索引，前缀（例如，INDEX(ext(50))）并不能真正解决您的问题。
• 外键只检查值是否存在;索引的类型（主要/唯一/索引）无关紧要。
• UUIDs在很多方面都是邪恶的;在可行的情况下避免它们。【我的看法。】
• 一张table增加了更多的蠕虫。
• INSERTing一行必须等待检查所有PRIMARY和UNIQUE键的重复，然后才能完成。其他二级密钥以“延迟”技术（使用“更改缓冲区”）插入。也就是说，最小化表中唯一键的数量有一点好处。