Redis不支持为不同database单独配置淘汰策略，因为所有DB共享同一内存池且DB仅为逻辑命名空间；maxmemory-policy全局生效，淘汰仅依据key属性（如TTL、访问频次）而非所属DB；替代方案包括多实例部署、key前缀+TTL分级、避免SELECT切库。
Redis 不支持为不同 database（SELECT 切换的 db0–db15）单独配置淘汰策略，maxmemory-policy 是全局生效的，所有数据库共用同一套淘汰逻辑。
为什么不能按 DB 配置淘汰优先级
Redis 的内存管理不区分 database，所有 key 无论属于哪个 db，都统一存放在一个共享的内存池中。淘汰触发时，Redis 只看 key 的属性（是否带 EXPIRE、访问时间、访问频次等），而不会检查它在哪个 db 下。database 在 Redis 内部只是逻辑命名空间，不是内存隔离单元。
这意味着：
- 即使你往 db0 存热数据、db1 存冷数据，allkeys-lru 仍可能把 db0 的 key 淘汰掉；
- volatile-lru 也只关心 key 是否设置了 TTL，不管它在哪个 db。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
CONFIG SET maxmemory-policy 的作用范围
该命令修改的是整个 Redis 实例的淘汰策略，对所有 database 生效，且立即覆盖之前设置：
-
CONFIG SET maxmemory-policy volatile-lfu→ 所有 db 中带 TTL 的 key 参与 LFU 淘汰 -
CONFIG SET maxmemory-policy allkeys-random→ 所有 db 的所有 key 都可能被随机删 - 哪怕你只在
db2写入大量数据，只要总内存超限，db0里没访问过的 key 同样会被淘汰
想实现“DB 级别优先级”的替代方案
既然无法靠配置实现，就得从应用层或部署层绕过限制：
- 用多个 Redis 实例：每个实例只服务一个业务模块，通过
maxmemory+maxmemory-policy独立控制，这是最干净的做法 - 给 key 加命名前缀 + 主动控制 TTL：比如
cache:hot:user:123设长 TTL，cache:tmp:session:abc设短 TTL，再配合volatile-ttl策略，让临时数据优先被淘汰 - 避免混用 db：官方早已不推荐用
SELECT切库，而是建议用不同实例或不同 key 前缀做隔离；Redis Cluster 根本不支持SELECT - 监控
evicted_keys和keyspace_hits/misses：确认淘汰是否误伤关键数据，而不是依赖“某个 db 更安全”这种错误预期
容易被忽略的关键点
很多人以为 FLUSHDB 能“释放某个 db 的内存从而影响淘汰倾向”，其实不会——FLUSHDB 只删 key，不改变当前内存使用量的统计基准；真正决定淘汰时机的是 used_memory_rss 和 maxmemory 的差值，和 db 数量、分布完全无关。另外，INFO memory 里的 mem_allocator 和 allocator_stats 有时会掩盖真实碎片情况，导致你以为还有空间，实际已触发淘汰。
