Redis中SCAN与KEYS的性能

包括官方Redis文档在内的许多资料都指出，KEYS由于可能会阻塞，在生产环境中使用该命令是一个坏主意。如果已知数据集的大致大小，相对于而言，是否SCAN有任何优势KEYS？

例如，考虑一个数据库，该数据库最多具有100个以下形式的键：data:number:X其中，X是整数。如果要检索所有这些，可以使用命令KEYS

data:number:*。这会比使用慢得多SCAN 0 MATCH data:number:* COUNT

100吗？还是在这种情况下这两个命令基本相同？可以说这SCAN是更好的选择，KEYS因为它可以防止出现意外的大集合返回的情况，这是否更可取？

您不必在乎当前命令的执行，而在乎对其他所有命令的影响，因为Redis使用单个线程来处理命令（即，在执行命令时，所有其他命令都需要等待直到执行一个结束）。

虽然keys还是scan可能会提供你的情况，单独执行你相似或相同的性能，几毫秒阻挡的Redis会显著降低整体I / O。

这是keys用于开发目的和scan生产环境的主要原因。

OP说：

“虽然键或扫描可能会为您提供单独执行的相似或相同的性能，但阻塞Redis的几毫秒会大大降低总体I / O。”
-这句话似乎表明一个命令阻止了Redis，而另一个则没有，这不是事实。如果可以保证我从KEYS呼叫中获得100条结果，那么哪种方式比SCAN糟糕？为什么您觉得一个命令更容易阻塞？

可以分页搜索时，应该会有很大的不同。被迫一次获得100个按键与能够实现分页并以10乘10（或50和50）的方式获得100个键并不相同。

。查看Redis官方文档对此有何评论：

由于这些命令允许增量迭代，每个调用仅返回少量元素，因此可以在生产中使用它们，而不会受到诸如KEYS或SMEMBERS之类的命令的不利影响，这些命令在被调用时可能会长时间（甚至几秒钟）阻塞服务器大量的键或元素集合

。