简而言之，是的，它当然会影响性能，因为密钥长度将直接影响沿着树走下去所需的时间。
它还会影响存储，因为较长的密钥需要更多的空间，空间需要时间。
然而，您忽略的细微差别是，虽然 Couch 可以（并且确实）为您分配新的 ID，但这不是必需的。它会非常乐意接受您自己的 ID，而不是生成自己的 ID。因此，如果密钥长度困扰您，您可以随意使用较短的密钥。
然而，考虑到 couch 的“json”性质，它几乎是一个基于“文本”的数据库。普通 Couch 实例中没有存储大量二进制数据（不支持附件，但即使我认为存储在 BASE64 中，我也可能是错的）。
因此，虽然 64 位是最有效的，但简单的事实是 Couch 被设计为适用于任何键，并且“任何键”最容易用文本表达。
最后，说实话，与磁盘 I/O 获取时间和数据的 JSON 编组（尤其是写入时）相比，键比较的成本相形见绌。通过转换到此类系统获得的任何实际收益可能不会对整体性能产生“现实世界”影响。
如果您想真正加快沙发钥匙系统的速度，请编写钥匙例程以将钥匙锁定为 64 位长整型，然后进行比较（就像您所说的那样）。8 字节文本与 64 位“long int”相同。理论上，这将使您在关键比较方面的性能提升 8 倍。erlang 是否可以创建这样的代码，我不能说。