unlink不能直接删除通配符前缀，因其不支持模式匹配，仅能作用于具体键名；必须先用scan安全遍历出匹配键，再批量传给unlink异步删除，避免阻塞且确保生效。
UNLINK 能安全删百万级集合，但必须配合 SCAN 使用，不能直接 UNLINK 通配符 —— 否则根本匹配不到 Key。
为什么不能 UNLINK order:* 这样写
Redis 所有原生命令（包括 UNLINK）都不支持通配符。写 UNLINK order:* 实际是尝试删除一个叫 order:* 的字面量 Key，而非匹配所有前缀为 order: 的 Key。这种写法不会报错，但返回值恒为 0，你以为删了，其实什么都没动。
-
KEYS order:*虽能列出，但在生产环境绝对禁用：它会遍历整个键空间，单线程阻塞，几百万 Key 可能卡住 Redis 几十秒 -
SCAN是唯一安全的遍历方式，它分批游标式扫描，不阻塞主线程 -
UNLINK必须作用于具体 Key 名，所以必须先SCAN出来，再逐个或批量传给UNLINK
怎么用 SCAN + UNLINK 安全删百万级集合
假设你要删所有 order:2025* 开头的 Key（其中很多是含百万元素的 ZSET 或 HASH），正确链路是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-cli --scan --pattern "order:2025*" -n 0流式输出匹配 Key（-n 0指定数据库编号） - 用
xargs批量喂给UNLINK，但要加-r防空输入，加-L 100控制每批最多 100 个 Key，避免参数过长或单次命令压力过大 - 完整命令：
redis-cli --scan --pattern "order:2025*" -n 0 | xargs -r -L 100 redis-cli -n 0 UNLINK
- 如果担心误删，可先用
SCAN输出到文件检查：redis-cli --scan --pattern "order:2025*" -n 0 > keys_to_unlink.txt，再人工抽样确认
UNLINK 对百万级集合到底做了什么
它不是“立刻释放内存”，而是两步分离：
- 主线程瞬间解除键空间引用，
EXISTS key立即返回 0，客户端感知不到延迟 - 真实内存回收交给后台
bio线程池处理，可通过INFO bio查看bio_pending_job_count是否堆积 - 注意：
used_memory指标不会马上下降，要等bio线程完成才更新；若bio_num_bgrewrite长期 > 0，说明后台任务积压，需排查是否同时在做BGREWRITEAOF或BGSAVE - 对长度 ≤ 64 的集合，
UNLINK仍走同步路径（因异步调度开销反而更大），但百万级肯定触发异步，无需干预
容易被忽略的三个硬性前提
漏掉任意一个，UNLINK 就会退化成无效操作或直接失败：
- Redis 版本必须 ≥ 4.0，低于此版本执行
UNLINK会返回ERR unknown command `unlink` - 集群环境下，
redis-cli必须启用--cluster模式，且SCAN+UNLINK要按 slot 分片执行，不能跨节点广播；单机模式无此限制 - Lua 脚本中禁止调用
redis.call("UNLINK", key)，会报错；若脚本逻辑依赖删除大 Key，必须拆出来由外部调用
真正危险的从来不是删得慢，而是删得“看似成功实则没删”——比如用错命令、版本不兼容、集群路由失效，这些都会让 Key 残留，而监控指标又暂时看不出异常。动手前务必在低峰期验证一次小范围前缀，确认 INFO memory 中 used_memory 确实缓慢回落，才算闭环。
