我喜欢在Redis中使用详细名称，例如set-allBooksBelongToUser:$userId。
这样可以，还是会影响性能？
你正在谈论使用的关键并不是那么久。
您给出的示例键是一组，设置查找方法是O（1）。集合（SDIFF，SUNION，SINTER）上更复杂的操作是O（N）。有可能填充$userId比使用更长的密钥更昂贵的操作。
Redis带有一个名为redis-benchmark的基准测试实用程序，如果你在src / redis-benchmark中修改了“GET”测试，这样他们的键只是“foo”，你就可以在make install之后运行短键测试：
diff --git a/src/redis-benchmark.c b/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);
这是短键“foo”的3次后续运行的GET测试速度：
59880.24 requests per second
58139.53 requests per second
58479.53 requests per second
这是再次修改源并将密钥更改为“set-allBooksBelongToUser：1234567890”后的GET测试速度：
60240.96 requests per second
60606.06 requests per second
58479.53 requests per second
再次改变密钥为“ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumsumloreipsumloreipsumloreipsumloreipsumsumloreipsrumloreplumipsipsumloreipsumloreipslorelumumumumumumumumumumumumumumumumumumumumumumumumumumumumumumumumumumipsumloreipsumumumumumipsumlorensloremlorem：1234567890”给出这个：
58479.53 requests per second
58139.53 requests per second
56179.77 requests per second
因此，即使非常长的按键也不会对redis的速度产生很大影响。这是在GET上进行的O（1）操作。更复杂的操作对此更不敏感。
我认为拥有明确标识它们所拥有的值的键大大超过了你从缩略键中获得的任何微小的速度性能。
如果你想进一步研究这个问题，redis-benchmark实用程序上还有一个-r [keyspacelen]参数可以创建随机密钥（只要它们中有'：rand：'），你可以增加前缀的大小。测试代码到你想要的任何长度。
Redis喜欢将所有密钥保存在内存中。平均密钥长度越长，内存中的密钥越少。所以，是的，密钥长度可以极大地影响性能，但可能不会像您所关注的那样显着。也就是说，对于小的键空间（例如，容易适合存储器的键空间），128字节键和16字节键将不会显着地不同地执行。
我无法肯定地回答这个问题。但是，我可以提出一些问题并提供一些观察。
我认为很明显，如果可以使用极长的密钥（名称）和/或值会对整体性能产生性能影响。这些影响可能发生在客户端，网络或服务器上。所以拖出你的第一个问题是：
Redis和您的客户之间的密钥和价值观有多长？
搜索Redis，密钥长度和限制让我在Redis vs. memcached上有一个有趣的博客文章，可能会开始回答你的问题。对该博客条目的第一个回应似乎是由Redis的创始人Salvatore Sanfilipo撰写的（去年秋天：2010年9月），这表明更新的版本会显示出更好的结果。两个评论从我们链接到Salvatore的Redis/memcached Benchmark，这是在他回应原来的“blagger”（似乎是匿名的）后几天发布的。
这不能回答问题（密钥可以使用多长时间，以及在哪些方面可以检测到对性能的影响）。但是，它为我们提供了解决问题的线索。
这两篇文章的作者都编写了代码并对其进行了测试......并绘制了结果图。
我们可以做出各种猜测。我们可以查看代码并尝试解释它。
然而，处理这种问题的最有意义的方法是编写一些代码来测量一个建议的使用模式......还有一些代码来测试另一个（例如，一系列密钥长度从8个字符到...如何你想要多长时间... 8千字节？）...并测量它。
我认为变量名称的长度不会影响性能，变量将占用与该数据类型的任何变量相同的位置，只要您没有超过最大名称长度。