与我合作的团队决定使用 varchar 主键创建一个表。此表被此主键上的另一个表引用。
我有创建整数主键的习惯，遵循我在大学学到的知识。我读到使用整数主键可以提高性能。
问题是我不知道创建整数主键的任何其他原因。你有什么建议吗？
【问题讨论】：
标签： sql performance indexing
VARCHAR 与 INT 的区别不大。重要的是访问模式。
就绝对而言，宽键总是比窄键差。类型绝对不重要，重要的是宽度。但是，与 INT 相比，很少有类型可以在狭窄方面胜过 INT，因此 INT 通常仅凭 4 个字节宽这一事实就胜出。
但真正重要的是集群键的选择。经常与主键混淆，两者代表不同的概念，并且不需要重叠。这是更详细的讨论Should I design a table with a primary key of varchar or int? 集群键的选择几乎是表设计中最重要的决定，而在其上机械应用INT identity(1,1) 可能只是一个人可能犯的最大错误。这是访问模式问题的来源：
总的来说，使用 INT IDENTITY 聚簇键可以破坏许多访问模式。因此，在开始应用千篇一律的解决方案之前，可能需要进行一些分析...
一些更一般的准则：
您会看到没有主键设计指南，因为主键不是存储设计的问题，而是建模的问题，并且完全由域驱动。
【讨论】：
主键应该代表行的标识，不应随时间改变。
我假设 varchar 是某种自然键 - 例如实体名称、电子邮件地址或序列号。如果您使用自然键，则有时可能会发生键需要更改的情况，例如：
通过使用代理键，您可以避免因必须更改主键而导致的问题。
【讨论】：
我有点失望，因为我已经 创建整数主节点的习惯 关键（按照一些老师所说的 我在大学）。我读了很多 性能文件 使用整数主键提升。
有一个术语：confirmation bias:
“也称为确认性偏见或 myside 偏见）是人们倾向于支持证实他们的先入之见或假设的信息，而不管它们是否真实。这导致人们选择性地收集新证据，以有偏见的方式解释证据，或选择性地从记忆中回忆信息。”
当然，您的第一反应会是：“但这不是真的！”是的，你会说'因为你有偏见;）[舌头牢牢嵌入脸颊]
这里有一个经典的例子：假设你的动物学教授告诉你所有的天鹅都是白色的，果然，你和你的朋友遇到的所有天鹅都是白色的。现在让我们说在以后的生活中，一位同事表达了这样一种观点，即也许有黑天鹅这样的生物。什么？！那不是你被教导的。你的世界被震撼了！你立即出去进行天鹅调查，你数了数 1000 只白天鹅和零只黑天鹅。证明！如果你发现了 10,000 只白天鹅，那么“所有天鹅都是白色的”假设会正确十倍，对吧？
另一种方法是暂时忘记白天鹅并尝试寻找黑天鹅。也许在阳光明媚的海边度假Dawlish？
我真的不想听起来不尊重；你承认阅读了很多关于你被告知的内容，这确实赢得了我的尊重。所以这是一个挑战：尝试找出不需要向表中添加整数列的情况。
这里有一些提示和剧透： 未被其他表引用的表；单列“全键”查找表；查询不多的“小”表:)
以下是您可能想调查的其他一些相关主题：
“主键”中的“主键”一词是否有很多含义，或者给定表中的所有键都相等？
“好”钥匙的品质是什么？ （例如，键的值应该是不可变的还是稳定性“足够好”？）
是否将整数列作为人工键（可能是因为可用的自然键不够“好”）或作为代理键（也许是为了提高原本“好”的自然键的性能）添加到表中？
当基于性能的原因将代理键添加到表中时，这是为了实际测量效果还是仅仅为了感知效果（即过早优化）？
代理键应该出现在逻辑业务模型中还是仅用于实现？
总是做某事（例如向表中添加一个整数列）而不每次都让大脑参与是个好主意吗？ ;)
[免责声明：我是一个天生的关键倡导者，并避免代理。对我来说，它们就像非规范化：你只在必要时才这样做，通常是针对性能问题（具体和可证明的），故障出在其他地方（糟糕的 SQL 产品版本、目前无法修复的逻辑设计缺陷等） ）。代理不应该出现在逻辑业务模型中。我有时需要一个人工标识符，甚至公开了它们的逻辑业务模型。]
【讨论】：