OBJECT IDLETIME 是识别僵尸Key最轻量安全的探针，需结合SCAN、TTL判断及三级清理策略：先确认无业务依赖，再隔离观察，最后用UNLINK分批删除。
OBJECT IDLETIME 本身不能直接“盘点僵尸Key”，但它是最轻量、最安全的探针——配合合理策略，能高效识别长期未被访问、又无过期时间的冷数据键。
明确“僵尸Key”的定义边界
生产中所谓“僵尸Key”，通常指同时满足以下三点的键：
- 没有设置 TTL（即永不过期）
- 已超过业务定义的“合理空闲阈值”（如 30 天、180 天）
- 当前仍存在于数据库中，且未被任何逻辑主动读写
注意：已过期但尚未被惰性或定期删除的键，OBJECT IDLETIME 返回 -2，不属于“僵尸”范畴，而是待清理的过期残留；不存在的键返回 -1，也不计入。
用 OBJECT IDLETIME 扫描的真实约束
该命令返回的是 LRU 时钟单位数，不是秒级精确值。默认分辨率是 1 秒，且 server.lruclock 每秒只更新一次。这意味着：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 返回值 86400 表示“至少空闲约 24 小时”，但无法区分是 24h00m01s 还是 24h59m59s
- 同一秒内被多次访问的键，IDLETIME 可能长时间为 0，不代表活跃，只说明它和当前时钟“撞上了”
- 不建议依赖 IDLETIME == 0 判断是否刚被访问；更可靠的是结合监控日志或客户端埋点
安全高效的全库扫描落地步骤
避免使用 KEYS *（阻塞主线程），改用渐进式 SCAN + IDLETIME 组合：
- 用 SCAN cursor COUNT 1000 分批遍历键空间，每次取 1000 个 key
- 对每个 key 执行 OBJECT IDLETIME，过滤出返回值 ≥ 阈值（如 12960000 = 150 天）的结果
- 跳过带 TTL 的键（可用 TTL key 判断，返回 ≥ 0 表示有到期时间，这类由过期机制兜底）
- 记录结果时，同步采集 TYPE、MEMORY USAGE（可选）和最后一次访问粗略时间（用 IDLETIME 反推）
示例脚本关键逻辑（Bash）：
redis-cli --scan | while read key; dotll=$(redis-cli ttl "$key" 2>/dev/null)
if [ "$tll" = "-1" ]; then # 无 TTL
idle=$(redis-cli object idletime "$key" 2>/dev/null)
if [ "$idle" -ge 12960000 ] 2>/dev/null; then
echo "$key $idle $(redis-cli type "$key")"
fi
fi
done > zombie_report.txt
识别后如何稳妥清理
发现僵尸Key不等于立刻 DEL。需分三级处理：
- 确认层：检查该 key 是否在监控系统、审计日志、慢日志中有近期痕迹；搜索代码库是否仍有注释残留或配置引用
- 隔离层：重命名 key（如 RENAME old:config:cache new:zombie:old:config:cache），观察 3–7 天业务是否异常
- 清理层：确认无依赖后，用 UNLINK（非阻塞删除）替代 DEL，尤其对大 Hash/List 更安全
切忌在高峰时段批量执行，建议在低峰期分批操作，并监控 used_memory 和 evicted_keys 指标变化。
