字符与整数主键

Question

我正在设计一个具有多个查找表的数据库，其中包含主要实体的可能属性。我正在考虑使用 4 或 5 个字符的键来标识这些查找值，而不是自动递增的整数，这样当我将这些属性 ID 存储在主表上时，我将看到有意义的值而不仅仅是随机数。

使用字符字段作为主键而不是整数对性能有什么影响？

如果这很重要，我正在使用 MySQL。

[编辑]
这些查找表很少添加新记录。它们是手动维护的，基于字符的密钥也是手动创建的。下面是一个例子：

      CUISINES
 ID      Description
-----  --------------
CHNSE  Chinese
ITALN  Italian
MXICN  Mexican

Answer 1

这取决于你的引擎。普遍的看法是，读取很便宜，这里和那里的几个字节不会显着影响中小型数据库的性能。

更重要的是，这取决于您将放置主键的用途。整数序列的优点是易于使用和实现。根据序列化方法的具体实现，它们还具有可快速派生的优点，因为大多数数据库只是将序列号存储在固定位置，而不是Select max(ID)+1 from foo即时派生。

问题变成了：一个 5 个字符的键如何为您和应用程序提供“有意义的价值”？这个值是如何创建的，与查找递增的序列号相比，它需要更多还是更少的时间。虽然在某些整数中节省了微不足道的空间量，但绝大多数系统将忽略这种空间节省。

除了字符方案要求永远不会有自动引擎之外，没有任何性能影响，因为您的“钥匙”是不可推卸的。对于您的特定域，不要理会人工键，只需使用中文、日语和泰语作为键名。虽然您不能保证任何可能的应用程序的唯一性，但在您的范围内使用它们而不是可怕的和强制的 5 个字符的缩写更为合理。在您获得数百万个元组之前，不会对性能产生重大影响。

或者，如果您只是按原产国而不是特定的区域美食（粤菜、四川菜、西西里菜、翁布里亚菜、卡拉布里亚菜、尤卡特坎菜、瓦哈坎菜等）进行跟踪，则始终可以只使用ISO 3166 代码。

如果我有 10,000 个食谱，5 个字符和 20 个字符的密钥之间的区别不会开始加起来吗？

空间便宜。当您谈论正在执行 OLAP 操作的 10,000,000 个配方时，那么，也许吧。使用 10k 食谱，您正在查看 150k 空间。

但同样，这取决于。如果您有数百万条记录，并且正在对它们进行连接，那么对这种微不足道的东西（到物化视图）进行非规范化查找是有意义的。出于所有实际目的，现代机器上 5 个字符的密钥和可变长度的密钥之间的相对连接效率非常相似。令人高兴的是，我们生活在一个拥有大量 CPU 和大量磁盘的世界中。讨厌的是连接太多和查询效率低下，而不是逐字符比较。话虽如此，请始终测试.

这种级别的 P&T 事物非常依赖于数据库，以至于泛化极其困难。建立数据库的两个样本模型，用估计的记录数填充它们，然后看看哪个更快。根据我的经验，与良好的索引、良好的内存配置和其他关键的性能调整元素相比，字符长度并没有太大的区别。

Answer 2

我认为，很少更改的表的性能没有问题。也许你将来会在设计上遇到问题。我建议您不要因为业务变化而使用业务数据作为主键。使用任何其他主键来“链接”模型中的表。任何业务更改都不会影响与此表相关的内容。