Spring Boot批量删除Redis缓存:使用RedisTemplate的delete(Collection)方法
RedisTemplate的delete(Collection)仅删除传入的key列表,不支持通配符。若keySerializer未设为StringRedisSerializer,keys()因默认序列化方式无法查找到字符串key。正确做法是先keys()获取所有匹配的key再delete(),但KEYS命令会扫描整个数据库导致阻塞,大实例慎用,建议用SCA
RedisTemplate 的 delete(Collection) 方法确实能执行批量删除操作,但它并非万能工具——它只会删除你明确传入的 key 列表,不支持通配符匹配,不会触发 FLUSHALL,更不会自动帮你查询 key。如果使用场景不当或序列化配置有误,就可能遇到删不掉、删得慢、甚至内存溢出(OOM)等问题,这些都是实际开发中常见的坑。

RedisTemplate.keys(pattern) 返回空?先检查序列化器配置
一个常见现象:调用 redisTemplate.keys("user:*") 总是返回空集合,但明明 Redis 中已经存在 user:1、user:2 这些 key。问题到底出在哪里?
根本原因在于:默认的 RedisTemplate 的 keySerializer 是 JdkSerializationRedisSerializer,它会使用 Java 序列化给 key 添加前缀(例如 \xac\xed\x00\x05),导致服务端收到的命令匹配的是经过序列化后的“乱码” key,而不是你期望的纯字符串。于是 KEYS 命令自然什么都查不到。
解决办法其实很简单:显式地将 keySerializer 设置为 StringRedisSerializer。尤其当你使用字符串作为 key 时,这一步必不可少。示例配置如下:
@Bean public RedisTemplateredisTemplate(RedisConnectionFactory factory) { RedisTemplate template = new RedisTemplate<>(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); template.setHashKeySerializer(new StringRedisSerializer()); // 其他序列化器按需设置... return template; }
如果不修改这个配置,keys("user:*") 永远找不到你存入的字符串 key——这个细节值得反复强调。
批量删除带前缀 key 的正确流程:keys + delete 分两步完成
Spring Data Redis 并没有内置“删除所有匹配前缀的 key”这样的原子方法,需要手动组合 keys() 和 delete(Collection)。具体应该如何实现?
redisTemplate.keys("order:*")返回的是Set,而不是List,可以直接传递给delete()方法。- 但需要注意:
KEYS是阻塞命令,在数据量较大的实例上使用要谨慎。生产环境推荐使用SCAN配合分批处理——不过RedisTemplate并未封装SCAN,需要自己编写逻辑。 - 一种简单安全的写法示例如下:
public void deleteByPrefix(String prefix) {
Set keys = redisTemplate.keys(prefix + "*");
if (keys != null && !keys.isEmpty()) {
redisTemplate.delete(keys); // 传入 Set,内部会转为 pipeline 批量发送 DEL
}
}
不必画蛇添足地将 keys 结果先转为 List 再转 Set,那样只会增加一次无意义的遍历。同样,也不要对空集合调用 delete(),虽然不会报错,但会浪费一次 Redis 往返通信。
delete(Collection) 的实际行为与限制
这个方法名称听起来像是“批量删除”,但底层实现其实是把集合中的每个 key 封装成一个 DEL 命令,通过 pipeline 发送——它既不是单条 DEL,也不是 FLUSHDB。具体细节需要留意:
- 传入
null或空集合:静默跳过,不会抛出异常。 - 传入不存在的 key:Redis 自动忽略,不影响其他 key 的删除操作。
- 传入 10 万个 key:可能触发 Redis 的
client-output-buffer-limit限制,或者导致客户端内存飙升(所有 key 都加载到 JVM 堆中)。 - 性能临界点:实测在千级 key 以内表现稳定;超过 5k 建议分批处理(例如每 500 个 key 一批),避免单次请求过大。
特别提醒:不要尝试将 "*" 传给 delete()——它不会展开通配符,只会去删除一个名为 "*" 的 key(几乎不存在)。
StringRedisTemplate 与 RedisTemplate:删除字符串 key 该选哪个?
如果你的 key 全部是字符串(例如 "user:1001"),优先使用 StringRedisTemplate。为什么?
StringRedisTemplate默认使用StringRedisSerializer,省去了手动配置序列化器的麻烦。redisTemplate.keys()和stringRedisTemplate.keys()的行为完全一致,但前者容易因序列化器配置错误而失效。- 两者的
delete(Collection)方法签名和逻辑完全相同,只是泛型约束不同。 - 混用风险:如果写入缓存时使用
RedisTemplate(JDK 序列化),而删除时使用StringRedisTemplate(字符串序列化),那么keys()查不到相应的 key,delete()也无法删除它们。
真正的关键不在于模板类名,而在于 key 序列化方式是否统一。在删除之前,务必确认写入时使用了哪种序列化器,不要等到查不到 key 时才开始怀疑人生。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
MyISAM索引文件与数据文件分离存储的原因解析
MyISAM将索引与数据分离存储,索引文件存磁盘地址,数据文件为堆表。该设计源于不支持事务、行锁及崩溃恢复,实现简单但代价较高:随机I O增加、表锁阻塞写入、无法利用覆盖索引,适合读多写少场景。
分布式系统全局防御SQL注入攻击的完整方案
全局防御SQL注入需在数据流转各节点设防:所有数据库访问强制参数化查询,禁用动态拼接;每个微服务使用独立最小权限账号;中间件拦截DDL关键词作兜底;ORM及分库分表组件防范隐性缺口,使拼接SQL难以隐藏。
Navicat连接Redis查看不同Slot槽位分布的方法
NavicatforRedis不显示槽位分布,需在命令行执行CLUSTERSLOTS查看连续槽段映射,或使用CLUSTERKEYSLOT定位特定key的槽号。节点列表仅反映拓扑发现,不包含真实槽范围信息,手动查槽才能避免被误导。
phpMyAdmin导入CSV时NULL关键字识别失败原因
phpMyAdmin导入CSV时,默认不将NULL文本或空单元格转为SQLNULL,需手动勾选“空字符串转为NULL”并填写NULL标识符,同时确保字段允许NULL、关闭引号,否则会存为字符串 NULL 或空字符串。
SQL查询嵌套层数过多导致执行计划失效的原因
嵌套超过3层时优化器放弃代价估算与条件下推,导致预估行数偏差三个数量级以上,MATERIALIZE和TableSpool高频出现。视图本质是文本模板,子查询被复制执行。CTE可能强制物化。扁平化关键在于让优化器准确估算行数并实现条件穿透。
- 热门数据榜
相关攻略
2026-07-20 07:03
2026-07-20 07:03
2026-07-20 07:03
2026-07-20 07:03
2026-07-20 07:02
2026-07-20 07:02
2026-07-20 07:02
2026-07-20 07:02
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程

