redis keys 有性能问题，用 scan 代替吗

keys 是阻塞，肯定不能用的。scan 你具体怎么用的？

不一定，如果是 GUI 管理工具的话用 scan 代替。正常使用要看具体需求，一般会避免用 KEYS 或 SCAN 遍历整个数据库，比如有的场景可以用一个 Set 键来代替

如果不要求在线处理的话
导出 rdb 慢慢分析不好么？

从官网文档：

> scan 相比 keys 具备有以下特点:

复杂度虽然也是 O(n)，但是它是通过游标分步进行的，不会阻塞线程;

提供 limit 参数，可以控制每次返回结果的最大条数，limit 只是对增量式迭代命令的一种提示(hint)，返回的结果可多可少;

同 keys 一样，它也提供模式匹配功能;

服务器不需要为游标保存状态，游标的唯一状态就是 scan 返回给客户端的游标整数;

返回的结果可能会有重复，需要客户端去重复，这点非常重要;

遍历的过程中如果有数据修改，改动后的数据能不能遍历到是不确定的;

单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零

scan 也是全表扫描。只不过是分段查询了。

下边是关于 scan 滥用引发的事故。

https://developer.51cto.com/art/202103/648155.htm

@awanganddong 这个例子很好

虽然 scan 带来的影响小于 keys ，但是理论上来说任何全量的检索应该避免在生产环境做，无论是 keys 还是 scan

之前做过一个工具，删除实例内某一类 key ，是用的 scan 做的，是在确认这个工具不会用于生产环境的前提下做的