回答:
使用について話している鍵は、実際にはそれほど長くはありません。
指定するキーの例はセット用で、セット検索メソッドはO（1）です。セット（SDIFF、SUNION、SINTER）のより複雑な操作はO（N）です。ポピュレーションは$userId、より長いキーを使用するよりも高価な操作だった可能性があります。
Redisにはと呼ばれるベンチマークユーティリティが付属していますredis-benchmark。src/ redis-benchmark.cの「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
再びキーを変更する「ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem：1234567890」この提供します：
58479.53 requests per second
58139.53 requests per second
56179.77 requests per second
したがって、本当に長いキーであっても、redisの速度に大きな影響を与えることはありません。そして、これはO（1）操作であるGETに関するものです。より複雑な操作は、これに対する感度がさらに低くなります。
保持している値を明確に識別するキーを持つことは、短縮されたキーから得られる非常に小さな速度パフォーマンスを大幅に上回っていると思います。
これをさらに進めたい場合-r [keyspacelen]は、redis-benchmarkユーティリティにパラメーターがあり、ランダムキーを作成できます（ '：rand：'が含まれている限り）。プレフィックスのサイズを増やすだけで必要な長さにコードをテストします。
Redisはすべてのキーをメモリに保持することを好みます。平均キー長が長いほど、メモリに保持できる量が少なくなります。そのため、はい。キーの長さはパフォーマンスに大きな影響を与える可能性がありますが、懸念される方法ではそれほど大きくない可能性があります。つまり、小さなキースペース（メモリに簡単に収まるキースペースなど）では、128バイトのキーと16バイトのキーのパフォーマンスが劇的に異なることはありません。
私はこの質問に確実に答えることはできません。しかし、それについていくつか質問したり、観察したりすることはできます。
極端に長いキー（名前）や値は、使用できる場合、全体的なパフォーマンスに影響を与えることは明らかです。これらの影響は、クライアント、ネットワーク、またはサーバーにあります。だからあなたの外に引きずる最初の質問は次のようになります：
キーと値は、Redisとクライアントの間でどれくらい長くできますか？
Redis、キーの長さ、制限を検索すると、Redisとmemcachedに関する興味深いブログエントリが見つかり、質問への回答が始まります。そのブログエントリへの最初の応答は、Redisの作成者であるSalvatore Sanfilipoによって作成されたようです（昨年秋の初旬：09/2010）、より新しいバージョンのほうがはるかに優れた結果を示すことを示唆しています。その下の2つのコメントは、SalvatoreのRedis / memcachedベンチマークにリンクしています。このベンチマークは、元の "blagger"（匿名のようです）に応答した数日後に投稿されました。
これでは、質問に答えることはできません（キーの長さはどれくらいで、どの時点でパフォーマンスに検出可能な影響があるか）。しかし、それは質問へのアプローチについての手がかりを与えてくれます。
これら両方の記事の作成者は、コードを記述してテストし、結果をグラフ化しました。
私たちはあらゆる種類の推測をすることができました。私たちはコードを見て、それを推理しようとすることができます。
ただし、この種の質問にアプローチする最も意味のある方法は、提案された使用パターンを測定するコードを記述し、さらに別のパターンをテストすることです（たとえば、8文字から...の範囲のキー長の範囲...長いですか... 8キロバイト？）...そしてそれを測定します。
変数名の長さがパフォーマンスに影響することはないと思います。変数は、名前の最大長を超えない限り、そのデータ型に対して変数が取るのと同じ場所になります。