名称长度是否影响Redis的性能？
我喜欢在Redis中使用详细名称，例如set-allBooksBelongToUser:$userId 。
这是好的还是会影响性能？
你谈论的关键并不是那么长。
你给的例子键是一组，查找方法是O（1）。 一组（SDIFF，SUNION，SINTER）上更复杂的操作是O（N）。 有可能是填充$userId是比使用更长的键更昂贵的操作。
Redis提供了一个名为redis-benchmark的基准testing工具，如果您在src / redis-benchmark.c中修改了“GET”testing，以便它们的键值只是“foo”，则可以在make install之后运行短键testing：
diff --git a/src/redis-benchmark.cb/src/redis-benchmark.c --- a/src/redis-benchmark.c +++ b/src/redis-benchmark.c @@ -475,11 +475,11 @@ benchmark("MSET (10 keys)",cmd,len); free(cmd); - len = redisFormatCommand(&cmd,"SET foo:rand:000000000000 %s",data); + len = redisFormatCommand(&cmd,"SET foo %s",data); benchmark("SET",cmd,len); free(cmd); - len = redisFormatCommand(&cmd,"GET foo:rand:000000000000"); + len = redisFormatCommand(&cmd,"GET foo"); benchmark("GET",cmd,len); free(cmd);
下面是3个短键“foo”后续运行的GETtesting速度：
59880.24 requests per second 58139.53 requests per second 58479.53 requests per second
再次修改源并将密钥更改为“set-allBooksBelongToUser：1234567890”后，以下是GETtesting速度：
60240.96 requests per second 60606.06 requests per second 58479.53 requests per second
再次将关键变成“ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem：1234567890”给出这个：
58479.53 requests per second 58139.53 requests per second 56179.77 requests per second
所以即使真的很长的键对redis的速度没有太大的影响。 这是一个O（1）操作。 更复杂的操作对此会更不敏感。
我认为使用密钥清楚地标识出它们所持有的值远远超过了从缩略密钥中获得的极小的速度性能。
如果你想进一步学习，redis-benchmark实用程序中还有一个-r [keyspacelen]参数，它可以创build随机密钥（只要它们中包含'：rand：'），就可以增加尺寸在testing代码中的前缀的长度，无论你想要的长度。
Redis喜欢在内存中保存所有的密钥。 平均密钥长度越长，内存越less。 所以是的，钥匙长度可以大大影响性能，但可能不会显着的方式，你所关心的。 也就是说，对于一个小键盘空间（例如一个容易放入内存的键盘空间），一个128字节的键和一个16字节的键不会有显着的不同。
我无法肯定地回答这个问题。 不过，我可以就此提出一些问题并提供一些意见。
我认为很显然，如果可以使用的话，非常长的键（名称）和/或值会对整体性能产生性能影响。 这些影响可能在客户端，networking或服务器上。 所以，拖出你的第一个问题是：
Redis和客户之间的密钥和价值能持续多久？
在Redis上search关键字长度和限制，可以让我在Redis和memcached之间build立一个有趣的博客条目，可以开始回答你的问题。 对这个博客文章的第一个回应似乎是Redis的创build者Salvatore Sanfilipo（去年秋天：09/2010）写的，表明最近的版本会显示更好的结果。 从这个评论中，我们可以看到Salvatore的Redis / memcached Benchmark ，在他回应了原来的“blagger”（似乎是匿名的）几天后发布的。
这不能回答这些问题（钥匙可以使用多久，在哪些地方对性能有可察觉的影响）。 但是，它给我们提供了解决这个问题的线索。
这两篇文章的作者写了代码并对其进行了testing……并绘制了结果。
我们可以做出各种猜测。 我们可以看看代码，并尝试推理出来。
然而，处理这类问题的最有意义的方法是编写一些代码来衡量一个build议的使用模式…还有一些testing另一个（例如，从8个字符到…的范围的密钥长度你想要多久… 8千字节？）和它的措施。
我不认为variables名称的长度会影响性能，只要不超过最大名称长度，variables将会占用与该数据types相关的任何variables的相同位置。
