无索引2亿键Redis库：如何高效扫描删除指定模式数据？

当然可以通过限制每次扫描的返回数量（即COUNT参数）来优化扫描过程，这是针对超大规模Redis实例进行渐进式扫描的核心优化手段。

当前代码的问题 #

1. 未指定COUNT参数：默认情况下Redis会使用较小的count值，导致2亿条键的扫描需要极多次迭代，耗时自然拉满。
2. 客户端二次过滤浪费资源：先让Redis返回所有PREFIX:*@INDEX_A的键，再在客户端过滤哈希长度为64的条目，会把大量不符合要求的键（如128位哈希）传输到客户端，浪费带宽和CPU资源。

优化后的代码实现 #

public Flux<String> findGidsByDomain(String domain){
    // 用64个?精准匹配哈希长度，让Redis端提前过滤掉不符合的键
    String wildCastKey = "PREFIX:" + "?".repeat(64) + "@INDEX_A";
    ScanOptions opts = ScanOptions.scanOptions()
            .match(wildCastKey)
            .count(20000) // 设置每次扫描的预估返回数量，提升迭代效率
            .build();
    return redisTemplate.scan(opts)
            .map(key -> keyBuilder.fetchKey(key));
    // 无需客户端再过滤，Redis已返回符合要求的键
}

额外优化建议 #

• 分批批量删除：扫描到一批键后，使用UNLINK命令（而非DEL）批量删除，每批次建议控制在1000-5000条，避免大批次删除阻塞Redis主线程。
• 控制扫描速率：如果是生产环境，可在扫描批次之间加入短暂延迟（如100ms），或根据Redis的CPU负载动态调整COUNT值，避免扫描占用过多资源。
• 低峰期执行：选择业务流量最低的时段执行扫描和删除操作，减少对线上业务的影响。

为什么COUNT参数有效？ #

Redis的SCAN是渐进式迭代扫描，COUNT参数用于告知Redis每次迭代需要遍历的哈希槽数量（近似值）。设置合适的COUNT（如20000）能大幅减少总迭代次数，显著提升大库扫描的整体效率，避免长时间无响应的情况。

内容的提问来源于stack exchange，提问作者Dustin