关于redis的key增加是否能影响查询效率

数组为什么查询速度快

参考地址
参考地址
参考地址

1. 数组占用的内存空间是连续的
2. 数组中都为同一类型的元素

时间复杂度：
即使我们对一个已经排好序的数组通过二分查找法进行查找，时间复杂度也为O(logn)。我们更准确的说法是，数组通过角标进行随机访问的时间复杂度为O(1)

举例分析

我们可以拿一个长度为5的int数组为例，当我们执行了一段int[] arr = new int[5]后，计算机会给这个数组分配如下图所示的一段内存空间：

当我们访问角标为2的位置上的元素时我们可以直接通过计算得出该元素对于的内存位置：
1000+2∗4

其中1000是我们的基地址，2代表了我们的偏移量，4代表了每个元素所占内存的大小（int占4个字节）这样通过一次计算，我们就能直接找到数组中对应角标的位置了。

讲到这里，我们不妨再思考一个问题:
问题3: 数组为什么角标都是从0开始呢
大家想一想，如果我们的角标是从1开始的话，我们上面的公式是不是也得发生变化，就变成了下面这个样子：
1000+(3−1)∗4

这样的话，相对我们之前的公式，是不是平白的多了一次减法的运算？所以，我们角标采用的是相对于基地址的偏移量作为计数标准，这样可以加快我们访问的速度！

通过上面我们知道了，连续的内存空间跟相同类型的元素这两大利器决定了数组随机访问的特性。另外还需要补充的是，因为数组在内存空间中是连续的，所以CPU在读取时，可以对数组进行“预读”。什么是预读呢？CPU在从内存中加载数据时，会先把读取到的数组加载到CPU的缓存中。而CPU每次从内存中读取数据，并不是只读取那个特定的要访问的地址，而是读取一个数据块，并保存到CPU缓存中，然后下次访问内存数据的时候就会先从CPU缓存开始查找，如果找到就不需要再从内存中取，这样就实现了比直接访问内存更高效的访问机制（这样做的原因是因为，CPU处理数据的速度高于从内存中读取数据的速度）。

哈希表查询快速的解析

参考文档

HashMap或者HashSet快的原因：
其他查询慢的原因是对于键或者值查询上，因为键或者只没有按特定顺序保存，所以只能采用简单的线性查询，而线性查询是最慢的查询方式。

数组的特点是：寻址容易，插入和删除困难；
而链表的特点是：寻址困难，插入和删除容易。

redis数据库键空间

参考地址
字典的数据结构其实完全可以类比Java中的HashMap数据结构，两者都是哈希表。

Redis 是一个键值对（key-value pair）数据库服务器， 服务器中的每个数据库都由一个 redis.h/redisDb 结构表示， 其中， redisDb 结构的 dict 字典保存了数据库中的所有键值对， 我们将这个字典称为键空间（key space）：

键空间和用户所见的数据库是直接对应的：

• 键空间的键也就是数据库的键， 每个键都是一个字符串对象。
• 键空间的值也就是数据库的值， 每个值可以是字符串对象、列表对象、哈希表对象、集合对象和有序集合对象在内的任意一种 Redis 对象。

举个例子， 如果我们在空白的数据库中执行以下命令：

那么在这些命令执行之后， 数据库的键空间将会是图 IMAGE_DB_EXAMPLE 所展示的样子：

alphabet 是一个列表键， 键的名字是一个包含字符串 “alphabet” 的字符串对象， 键的值则是一个包含三个元素的列表对象。
book 是一个哈希表键， 键的名字是一个包含字符串 “book” 的字符串对象， 键的值则是一个包含三个键值对的哈希表对象。
message 是一个字符串键， 键的名字是一个包含字符串 “message” 的字符串对象， 键的值则是一个包含字符串 “hello world” 的字符串对象。

因为数据库的键空间是一个字典， 所以所有针对数据库的操作 —— 比如添加一个键值对到数据库， 或者从数据库中删除一个键值对， 又或者在数据库中获取某个键值对， 等等， 实际上都是通过对键空间字典进行操作来实现的， 以下几个小节将分别介绍数据库的添加、删除、更新、取值等操作的实现原理。

如果你的Redis命令都是单个key比较多，O(1)操作，基本性能和key多少没有太大关系。