Redis里查集合有多快？大小到底咋算，今天就来聊聊这个事儿

今天咱们就来聊聊Redis里的集合,主要关心两个事儿：第一，在Redis里查一个集合有多少个成员，速度到底有多快？第二，这个“大小”是怎么算出来的，会不会很占内存？咱们用大白话把它讲明白。

先说说查集合大小有多快

在Redis里,查一个集合（Set）有多少个成员，用的命令是SCARD key，这个操作的速度，可以这么说，快得飞起，基本上是瞬间完成，为啥能这么快呢？这跟它的实现方式有关系。

根据Redis官方文档（来源：Redis官方文档关于SCARD命令的说明）的解释，SCARD命令的时间复杂度是O(1)，这个O(1)是计算机里的一个术语，意思就是说，无论你这个集合是只有1个成员，还是有100万个成员，我查询它所花的时间都是一样的，都是一个恒定的、非常短的时间。

这就像是你有一本厚厚的电话簿,你想知道这本电话簿里总共记录了多少个电话号码，一个笨办法是从第一页开始，一页一页地数，直到最后一页，如果电话簿有1000页，你就得数1000下；如果有10000页，你就得数10000下，这种方法的速度就跟电话簿的厚度（数据量）成正比，这叫O(N)，速度会随着数据量增大而变慢。

但Redis用的不是这种笨办法,它非常聪明，它在日常维护这个集合的时候，就悄悄地在一个小本本上记下了成员的总数，当你问它“这个集合有多大？”的时候，它根本不需要去遍历集合里的每一个成员，只需要低头看一眼那个小本本上记的数字，然后马上告诉你答案，无论集合多大，它都只做“看一眼”这一个动作，速度自然是恒定的、极快的。

你可以放心地在你的程序里频繁使用SCARD命令来获取集合大小，完全不用担心性能问题，Redis在设计上就已经帮你把这种常见操作的效率优化到极致了。

再来聊聊集合的大小是怎么算的

这里说的“大小”其实有两个层面的意思：一是我们刚才说的成员个数，二是它实际占用的内存空间，成员个数就是SCARD返回的那个数字，很清楚，但占用的内存空间就有点讲究了。

Redis的集合底层并不是只用一种数据结构实现的,它会根据情况“看人下菜碟”，选用最节省内存的方式，主要有两种内部编码（来源：Redis源码和内存优化相关文档）：

1. intset（整数集合）：当集合同时满足两个条件时，Redis就会使用这种结构：

   • 集合里的所有成员都是整数。
   • 成员的数量相对较少（由一个配置参数决定，比如默认是512个以下）。 intset的特点是非常紧凑，它会把所有整数按顺序存放在一块连续的内存里，比如你存了数字1, 3, 5，它就真的在内存里一个挨一个地存下1、3、5，这种方式查找效率高，而且没有一点多余的空间浪费，非常节省内存，你可以把它想象成一个紧紧捆在一起的甘蔗捆。

2. hashtable（哈希表）：一旦不满足上述两个条件（比如你存了非整数的字符串，或者成员数量超过了阈值），Redis就会自动把集合的内部结构从intset转换成hashtable。 hashtable是字典结构，它能支持任意类型的数据，并且查找、添加、删除的平均速度也很快（也是O(1)），它需要维护一个数组（通常这个数组的大小会比实际元素个数大，以减少冲突），每个元素实际上是一个链表的指针，hashtable虽然功能强大、速度快，但它会有一些额外的内存开销，比如指针占用的空间、数组预分配的空间等，这就像是一个有很多格子的储物柜，即使有些格子是空的，柜子本身也得占那么大的地方。

   

回答“集合的大小咋算”这个问题，结论是：成员个数就是实际添加进去的成员数量，很简单；但占用的内存大小，则取决于Redis底层用了哪种结构来存它。 用intset存的小整数集合，内存利用率极高；而用hashtable存的大集合或者包含字符串的集合，内存开销会相对大一些。

怎么能知道一个集合具体用了哪种结构呢？

你可以使用Redis的OBJECT ENCODING key命令来查看，比如你有一个集合叫myset，你输入OBJECT ENCODING myset，它可能会返回intset或者hashtable，这能帮你更好地理解你的集合在内存中是如何被表示的。

总结一下

今天咱们聊了Redis集合的两个核心点：查询大小和内存占用，查询集合的成员数量（SCARD）是非常快的，是O(1)操作，因为它直接返回一个预先计算好的值，你可以随便用，而集合的内存占用则更复杂，Redis会智能地根据集合内容选择最节省空间的内部结构（intset或hashtable），理解这一点，有助于你在设计数据模型时，有意识地利用intset的特性（比如尽量使用整数ID）来优化内存使用，希望这番大白话的解释，能让你对Redis集合的“大小”有个清晰的认识。