SCAN 0 MATCH user:* COUNT 500 SCAN 1024 MATCH user:* COUNT 500 INFO keyspace DBSIZE
运维在线上敲了一次 KEYS user:*，实例 CPU 瞬间 100%，业务请求超时八千多毫秒。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：KEYS 会一次性遍历整个键空间，遍历没结束前不返回任何结果，键越多阻塞越久，主线程被占住时所有命令都在排队等着。
围绕「Redis SCAN 遍历」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
处理上按这个顺序：所有遍历改用 SCAN 每次带 COUNT 控制批量；游标要一直循环到返回 0 才算真正结束遍历；清理任务放到从库去跑 或者挪到低峰期执行。
确认没问题再收工，遍历期间实例延迟稳在 2 毫秒内，扫出的键数量与 DBSIZE 接近。