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

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

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

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

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

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

空间很便宜。当您谈论 10,000,000 个您正在对其进行 OLAP 操作的食谱时，也许。使用 10k 食谱，您将看到 150k 的空间。

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

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