redis的keys命令类似于Mysql的like命令，无非就是模糊匹配相近的字符数据。

KEYS 的速度非常快，但在一个大的数据库中使用它仍然可能造成性能问题，如果你需要从一个数据集中查找特定的 key ，最好还是用 Redis 的集合结构(set)来代替，我们在实际生产环境中请求并发比较多的地方还是最好忽略掉，如果仅仅为我们开发人员所用到的地方，可以偷偷用一下。因为Keys会引发Redis锁，并且增加Redis的CPU占用，情况是很恶劣的，如果数据庞大的话可能需要几秒或更长。

如果有这种需求的话可以自己对键值做索引，比如把各种键值存到不同的set里面，分类建立索引，这样就可以很快的得到数据，但是这样也存在一个明显的缺点，就是浪费宝贵的空间，要知道这可是内存空间啊，所以还是要合理考虑，当然也可以想办法，比如对于有规律的键值，可以存储他们的始末值等等。

虽然redis只提供了五种类型，但是用起来不一定就只有五种，比如string类型，你可以存储任何你自己定义的类型，所以思想不能局限，灵活的设定数据结构。还有就是虽然redis存取很快，但是正常生产环境，redis服务器肯定和web服务器不是在一起，有时候甚至是在不同的地区，所以网络通信延迟就很重要了，所以要减少存取次数，一次存取完成更多的工作，否则你会发现做同样的事redis还没有关系型数据库快，所以redis存的时候一定要有技巧，尽可能减少存取次数。

从redis的官方文档上看，2.8版本之后SCAN命令已经可用，允许使用游标从keyspace中检索键。对比KEYS命令，虽然SCAN无法一次性返回所有匹配结果，但是却规避了阻塞系统这个高风险，从而也让一些操作可以放在主节点上执行。

需要注意的是，SCAN 命令是一个基于游标的迭代器。SCAN 命令每次被调用之后， 都会向用户返回一个新的游标，用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来延续之前的迭代过程。同时，使用SCAN，用户还可以使用keyname模式和count选项对命令进行调整。SCAN相关命令还包括SSCAN 命令、HSCAN 命令和 ZSCAN 命令，分别用于集合、哈希键及有续集等。

另一方面，使用redis的时候一定要注意控制key，对于key的命令要制定一个完善的方案，这样才能对redis里面的数据可控，避免出现没用数据长时间占据数据库这种情况，也可以避免上面说的这种查询键值的操作。

还可以看下这篇文章：

KEYS 的速度非常快，但在一个大的数据库中使用它仍然可能造成性能问题，如果你需要从一个数据集中查找特定的 key ，你最好还是用 Redis 的集合结构(set)来代替