您正在谈论使用的密钥并没有那么长。
您提供的示例键用于一个集合，集合查找方法为O（1）。集合（SDIFF，SUNIOn，SINTER）上更复杂的操作是O（N）。可能的是，
$userId与使用较长的键相比，填充是更昂贵的操作。
Redis带有一个称为的基准实用程序
redis-benchmark，如果您修改src / redis-benchmark.c中的“
GET”测试，使其键仅是“ foo”，则可以在a之后运行短键测试
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 second58139.53 requests per second58479.53 requests per second
这是再次修改源并将密钥更改为“ set-allBooksBelongToUser：1234567890”后的GET测试速度：
60240.96 requests per second60606.06 requests per second58479.53 requests per second
再一次改变的关键在于“ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem：1234567890”给出了这样的：
58479.53 requests per second58139.53 requests per second56179.77 requests per second
因此，即使是非常长的键也不会对Redis的速度产生重大影响。这是在GET上的O（1）操作。更复杂的操作对此甚至不那么敏感。
我认为，拥有可以清楚地识别出它们所持有的价值的钥匙大大超过了您从缩写钥匙中获得的任何微不足道的速度性能。
如果您想进一步说明这一点，那么
-r [keyspacelen]redis-
benchmark实用程序上还有一个参数，可以让它创建随机密钥（只要它们中包含’：rand：’），您就可以在其中增加前缀的大小。测试代码到您想要的长度。
