问短文本数据库键与数字键；什么时候比另一个更有效？

EN

在大多数情况下，由业务需求(用例)驱动的考虑因素将远远超过数字与文本键之间的任何性能差异。除非您考虑的是非常大的和/或非常高的吞吐量系统，否则主键类型的选择应该基于密钥的使用方式，而不是数字键和文本键在性能上的微小差异。

在集会中思考，找出答案。你说过：

我们可以假设使用char(2)字段可能比使用int键更有效，因为char数据是2字节，而与int一起使用的是4字节。从理论上讲，使用smallint域与char(2)域以及可能的varchar(2)域一样有效。

这不是真的，因为你不能在一条指令中同时移动两个字符(据我所知)。因此，即使一个char比一个4字节的int小，你也必须一个一个地将它们移动到寄存器中来进行比较。要比较4字节int的两个实例，即使它的大小更大，每个int只需要1次移动指令(不需要将它们从寄存器中移回内存)。

那么如果您使用int会发生什么呢？

• 将其中一个移动到一个寄存器中
• 把另一个移到另一个
• 做比较操作
• 根据比较结果移动到适当的内存位置

然而，在char的情况下：

• 将其中一个移动到一个寄存器中
• 把另一个移到另一个
• 做一个比较
  • 如果您很幸运，并且可以确定订单，那么就可以完成，并且成本与int的相同。
  • 如果它们相等，则使用后续字符进行清洗和重复，直到确定顺序或相等为止。显然，这样做的代价更高。

​

要点是，在低级别上，决定因素不是数据大小，而是所需指令的数量。

除了低级的东西：

• 是的，在某些情况下，它根本不重要，因为很少的数据是不可能改变的-例如，原始元素的化学符号(虽然我不确定我是否会用它们作为PKs)。
• 一般来说，你不会使用人工的PKs来考虑时间和空间，但是如果它们与现实生活中的东西没有任何关系，它们就不会被改变。你能想象一个美国国家的名字会发生变化吗？我可以的。如果发生这种情况，您必须更新记录本身(如果缩写也发生了变化，ofc.)，以及引用它的所有其他记录。如果您使用的是int，那么您的记录将与实际发生的情况无关，在这种情况下，您只需更新缩写和状态名称本身，您就可以放心地确保一切都是一致的。
• 比较短字符串并不总是像比较它们的二进制表示的数值一样简单。当您还必须考虑国际化时，您需要依赖自定义(或框架/平台提供的)逻辑来比较它们。以我的语言为例，字母‘α’的小数值为193，大于字母'B‘的’66‘，然而，在匈牙利字母中，’安赫斯‘先于'B’。
• 使用文本数据而不是官方数字PK也会导致一些碎片，而且写操作可能会更慢。这样做的原因是，人为的、单调增加的数值PK将导致新创建的行在所有情况下都插入到表的末尾，从而避免了“在两者之间移动空间”的需要。