我明白你遇到的麻烦了——用CrudRepository.deleteAll()删除大体积的Redis Hash相关数据时，因为一次性处理的数据量太大，导致了连接中断的JedisConnectionException: Unexpected end of stream异常，生产环境里这种问题确实头疼。咱们一步步来解决：

先搞清楚你的Redis数据结构 #

首先要明确：你用@RedisHash("UserChatsViewEntity")注解的实体，Spring Data Redis默认的存储方式是每个实体对应一个独立的Hash，key格式为UserChatsViewEntity:{id}，同时会维护一个名为UserChatsViewEntity的Set，用来存储所有实体的ID（做索引用）。这和你以为的“单个大Hash”可能不一样——如果真的是单个大Hash（key就是UserChatsViewEntity，内部存多个field-value），那删除起来反而简单。

为什么deleteAll()会报错？ #

CrudRepository.deleteAll()的逻辑是先调用findAll()把所有实体拉取到内存，再批量删除。当数据量很大时，不仅会占用大量内存，还会让Redis连接长时间处于忙碌状态，最终导致连接超时、流中断，就是你遇到的异常。

你尝试的代码问题在哪？ #

你写的opsForSet().scan()逻辑方向是对的，但有几个小问题：

1. 你只删除了Set里的ID元素，没删除对应的实体Hash（UserChatsViewEntity:{id}）；
2. 对count(100)的理解有误——这个参数不是限制删除数量，而是告诉Redis每次扫描返回大约100个元素，避免一次性拉取太多数据压垮连接，是分批处理的关键配置。

可行的解决方案 #

方案1：如果是单个大Hash（key=UserChatsViewEntity）

直接删除整个Hash的key就行，这是Redis的原子操作，速度极快，完全不会有性能问题：

redisTemplate.delete("UserChatsViewEntity")

方案2：如果是Spring Data Redis默认的多Hash+索引Set结构

用scan分批遍历索引Set里的ID，批量删除对应的实体Hash，最后删除索引Set：

// 分批扫描索引Set中的所有实体ID
redisTemplate.opsForSet().scan("UserChatsViewEntity", ScanOptions.scanOptions().count(100).build()).use { cursor ->
    val batchSize = 100
    val hashKeysToDelete = mutableListOf<String>()
    
    while (cursor.hasNext()) {
        val entityId = cursor.next()
        // 构造实体对应的Hash key
        hashKeysToDelete.add("UserChatsViewEntity:$entityId")
        
        // 每攒够100个key就批量删除，减少Redis交互次数
        if (hashKeysToDelete.size >= batchSize) {
            redisTemplate.delete(hashKeysToDelete)
            hashKeysToDelete.clear()
        }
    }
    
    // 删除剩余的未批量处理的Hash key
    if (hashKeysToDelete.isNotEmpty()) {
        redisTemplate.delete(hashKeysToDelete)
    }
}

// 最后删除存储ID的索引Set本身
redisTemplate.delete("UserChatsViewEntity")

关键注意事项 #

• 生产环境禁止用keys命令：keys会遍历Redis所有key，阻塞服务，必须用scan代替；
• 分批处理的必要性：不管是扫描还是删除，都要控制单次操作的数据量，避免连接超时；
• count(100)的作用：它是Redis扫描的“批次建议值”，Redis会根据内部情况返回近似数量的元素，核心是避免一次性返回过多数据导致连接溢出。

内容来源于stack exchange