在Redis中使用GUID（或类似）会导致性能损失吗？

使用GUID或ulong键是否会影响Redis DB性能

---

类似：

我可以想到GUI的两个问题：

它们不是顺序的

我不确定Redis，但是如果主键值是顺序的，许多数据库（SQL Server、MongoDB）可以更高效地索引

也许Redis与此类似

有其他GUID生成算法可以生成顺序GUID来解决此问题，例如

或SQL Server的

它们很大

---

键越长，存储索引所需的内存就越多。GUID为128位。在许多（大多数）数据库中，还可以使用64位或32位密钥。使用32位整数的GUID意味着您将使用4倍的内存作为索引。由于许多数据库的索引比物理内存大得多，这可能会对性能产生显著影响。

Redis使用哈希策略存储所有密钥，每个密钥都使用哈希函数存储。所有关于按键的Redis db性能都属于此功能或相关功能

---

原始密钥也被存储起来，以确定不同密钥之间未来的一致性，是的，大密钥可能会影响内存句柄和所有相关字段：内存碎片、缓存命中/未命中等…

这个问题很老，但其他答案有点误导。Eric的回答与Redis完全无关。普弗里克斯的答案是基于个人假设，完全错误

事实上，使用GUID键是相当安全的（性能方面），因为即使是300多个字符的键也不会对O（1）操作的性能产生显著影响。检查此基准：

如果使用十六进制表示，GUID的长度通常为32-36个字符。正如Evan Carrol在评论中所注意到的，Redis字符串是二进制安全的，因此您可以使用二进制值并将密钥大小减少到128位（16个字符）。这样长的键根本不会影响性能

---

另外，文档建议对真正大的键使用哈希函数：

谢谢Eric的评论。但redis db有着如此不同的体系结构，我通过更多的研究找到了答案。。致以最良好的问候。很抱歉投了反对票，但他的问题对Redis来说非常具体。如果他的问题不包括REDIS，那么答案很好：-）您不会提供错误信息，但基于REDIS的实现，您的推理不适用于REDIS。由于redis本质上是一个键值存储，针对键访问进行了大量优化，因此顺序键除了可能更容易在代码中迭代之外没有任何意义。对于大小限制，没有什么有意义的影响，因为Redis建议密钥小于1024字节。guid远远达不到这一点。唯一的潜在问题是，所有内容都存储在内存中，因此，如果您的值小于密钥大小，则大部分存储空间将分配给密钥。如果有人问我，我会回答为。但有人做了测试，这似乎很有趣。这个答案是误导性的，正如@ozz在上面的评论中提到的，即使300+字符键也不会影响性能。这个链接有性能基准，公认的答案说不重要“UUID的长度为128位，就像md5sum一样。它与字符无关。