Performance 当两个输入集之一为正常集时，zinterstore是否会更快/更慢？

我知道我可以用一个正规集作为参数（）来进行zinterstore。这会影响性能吗？它是否会比仅使用zsets更快/更慢？

Redis默认情况下假设正常集的每个元素都有一些默认分数，因此它将正常集视为一个排序集，所有元素的默认分数相等。我认为性能应该与相交2个排序集相同。

根据，

ZINTERSTORE

将一个集视为得分为1的排序集，函数名为zunionInterGenericCommand

相交集将花费更多或更少的时间，具体取决于此步骤中使用的排序算法，例如：

   /* sort sets from the smallest to largest, this will improve our
     * algorithm's performance */
    qsort(src,setnum,sizeof(zsetopsrc),zuiCompareByCardinality);

set和zset的存储方式也存在差异，这将影响它们的读取方式。Redis将根据包含的元素数量决定如何对一个（已排序的）集合进行编码。因此，遍历它们需要做不同的工作

然而，出于任何实际目的，我认为您最好的选择是使用

ZINTERSTORE

，我将解释原因：我几乎看不出您在源代码中编写的任何东西在进行您想要的交叉时会如何击败Redis性能

如果你关心的是性能，那么你对细节的关注就太多了。您的焦点应该放在操作的大O上，如命令所示：

时间复杂度：O（NK）+O（Mlog（M））最坏情况，N为 最小输入排序集，K为输入排序集的数量，和 M是结果排序集中的元素数

这告诉你的是： 1-较小集合的大小和计划相交的集合数量决定第一个零件。因此，如果你知道你将始终相交于两个集合，一个是小的，另一个是大的；那么你可以说第一部分是常数。这方面的一个很好的例子是，将商店中所有可用产品的集合（分数为库存数量）与用户购物车中已排序的产品集合相交

在这种情况下，您将只有2套，并且您将知道其中一套非常小

2-结果排序集M的大小可能会导致严重的性能问题。但这里有一个技巧：当大的排序集太大时，它们被编码为跳过列表。一个小的排序集将存储为zip列表，这可能会在大的排序集中造成重大影响

但是，对于交叉点的情况，您知道结果集不能大于您提供的较小集。对于并集，结果集将包含所有集合中的所有元素；因此，人们需要更多地关注较大集合的大小，而不是最小集合的大小

总之，对于（排序）集合的性能问题的答案是：它取决于集合的大小，而不是实际的数据类型。考虑到结果数据结构将是一个排序集，而与所有输入集无关。因此，一个较大的排序集将作为跳过列表存储（效率较低）

---

事先知道计划相交的集合数（2，3，取决于用户输入？）和较小集合的大小（10？数百？数千？）将比内部数据类型提供更好的想法。相交的算法对于这两种类型都是相同的。

你有来源吗？试着用元素{a，b}建立一个集合，用元素{a，b}和分数{1，2}分别建立一个排序集合。现在，尝试使用一个聚合总和的zinterstore，您将看到redis默认为普通集合的所有元素分配了一个默认值，这不是我的问题。当然，redis就是这样做的。我想知道zset和set的内存使用情况是否相似。在zinterstore中组合它们是否比只使用zset慢/快。问题只是询问数据类型是否不同是否会影响性能。但是答案集中在big-O上。我认为答案有点离题。