Redis大key排查清理，避免缓存卡顿

Redis大key是指单个key的value体积过大，或者集合类型（Hash、List、Set、ZSet）元素数量过多。
它最容易引发缓存卡顿：读取时阻塞单线程、删除时导致主线程卡死、主从同步延迟飙升。
下面按“先排查、再清理、后验证”的顺序，给出零基础也能直接执行的命令和脚本。

先确认是否真的存在大key

登录Redis服务器，用redis-cli自带的扫描命令做初步筛查。
注意该命令会遍历所有key，建议在业务低峰期执行，或从从库上执行。

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword --bigkeys

输出会列出每种数据类型中最大的key及其大小（如Sampled 100000 keys in the keyspace!）。
如果看到某个String类型key超过10KB，或某个Hash/List元素数量超过5000，基本可以判定为大key。

进一步确认单个key的内存占用，用MEMORY USAGE（Redis 4.0+支持）：

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword MEMORY USAGE your_key_name

返回值单位是字节。单个key超过1MB，或者集合元素超过1万，就属于需要关注的大key。

分步清理大key，避免二次卡顿

直接DEL大key会触发同步释放内存，导致Redis主线程阻塞数秒甚至更久。
正确做法是渐进式删除。

对String类型：直接删除即可

String类型删除开销小，但若value极大（如几百MB），仍建议在低峰期操作：

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword DEL your_big_string_key

对Hash/List/Set/ZSet：使用HSCAN/SSCAN/ZSCAN分批删除

以Hash为例，先查看元素数量：

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword HLEN your_big_hash

然后用HSCAN游标遍历，每次删除一批字段：

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword HSCAN your_big_hash 0 COUNT 100

实际清理时，建议写一个Lua脚本或Shell循环，每次删除100~200个元素，间隔0.1秒，直到key被删空。
也可以用Redis 4.0+的UNLINK命令替代DEL，它会在后台线程异步释放内存，不阻塞主线程：

redis-cli -h 127.0.0.1 -p 6379 -a yourpassword UNLINK your_big_hash

如果Redis版本低于4.0，必须用分批删除，不能直接DEL大集合。

避坑指南：这些操作容易让缓存更卡

• 不要在业务高峰期执行--bigkeys：该命令会扫描全量key，可能拖慢响应。
• 不要用KEYS *找大key：KEYS会阻塞Redis，生产环境禁止使用。改用SCAN系列命令。
• 不要直接DEL大Hash或大List：同步释放内存可能造成秒级卡顿，优先用UNLINK或分批删除。
• 主从架构下注意同步延迟：删除大key后，主库产生大量删除操作，从库可能延迟。建议观察INFO replication中的master_repl_offset差值。
• 清理前先备份：如果不确定key是否还在用，先用DUMP导出或从备份恢复，避免误删业务数据。

验证清理效果与日常预防

清理完成后，重新执行redis-cli --bigkeys确认最大key体积已下降。
同时用INFO memory查看used_memory_human是否回落，用SLOWLOG GET 10检查是否还有大key引发的慢查询。

日常预防建议：

• 写入前预估value大小，String类型控制在10KB以内，集合元素控制在5000以内。
• 对可能增长的集合key，定期用HLEN、LLEN、SCARD、ZCARD监控长度。
• 在代码层做拆分，例如把大Hash按用户ID分片成多个小Hash。

大key清理的核心原则是：先定位、再异步删、后验证。 只要按上面的命令一步步操作，就能在不影响业务的前提下解决缓存卡顿问题。

常见疑问

--bigkeys显示没有大key，但Redis还是卡，怎么办？

检查慢查询日志SLOWLOG GET，可能是热点key或复杂命令导致，不一定是体积大。

UNLINK和DEL有什么区别？

DEL同步释放内存，可能阻塞；UNLINK把释放操作放到后台线程，适合大key。

清理后内存没降下来？

Redis内存回收有延迟，可执行MEMORY PURGE（Redis 4.0+）或等待后台任务完成。

从库上执行--bigkeys安全吗？

从库同样会消耗CPU，建议在低峰期操作，或使用--bigkeys的-i参数控制扫描间隔。