SINTER性能随标签集合增大而下降，因其时间复杂度为O(N×M)，N为最小集合大小，M为集合数量；当存在大集合（如300万ID的通用标签）时，P99耗时可达120ms+且无超时机制，易阻塞服务；生产环境应改用SINTERSTORE预计算+TTL缓存方案。
为什么直接用 SINTER 做标签交集可能变慢
当用户打的标签越来越多，比如「Java」「Spring」「分布式」「高并发」，对应每个标签都存一个 Set（如 tag:java、tag:spring），用 SINTER tag:java tag:spring tag:distributed 求共同文章 ID 时，Redis 会逐个遍历最小集合再做成员存在性检查。如果某个标签覆盖了 50 万篇文章，而其他标签只有几千，它仍要对这 50 万次做 O(1) 查找——总耗时就不是常数级了。
更关键的是：SINTER 不支持超时控制，也不返回中间结果；一旦某次请求拖慢，整个服务响应就被卡住。
- 实际压测中，4 个平均大小为 20 万的
Set做SINTER，P99 耗时可达 120ms+ - 若其中有一个标签是“热门通用标签”（如
tag:tech含 300 万 ID），性能会断崖式下跌 - Redis 7.0 仍未改变
SINTER的单线程同步执行模型，无法并行化子集扫描
SINTERSTORE + 过期时间才是生产环境的安全做法
别在每次请求里实时算交集。把高频组合预计算成新集合，并设好 TTL，既保时效又降压力。
例如：用户常搜「Java + Spring」，可定时或事件触发执行：
SETEX cache:tag:java-spring 3600 "1"
然后用 SINTERSTORE 写入结果（注意：目标 key 必须不存在或为空，否则会追加）：
SINTERSTORE temp:java-spring tag:java tag:spring
再给结果集合设过期：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
EXPIRE temp:java-spring 3600
-
SINTERSTORE是原子操作，不会出现中间态脏数据 - 结果集合用
temp:前缀隔离，避免和业务 key 冲突 - TTL 设为 3600（1 小时）比永不过期更安全：即使上游标签变更，最多延迟 1 小时生效
- 若需强一致性，可在标签更新后主动
DEL temp:java-spring，下次请求重建
用 SDIFF 实现“排除类”标签过滤要小心顺序
想查「Java 开发者但不关注 AI」，直觉写 SDIFF tag:java tag:ai —— 这是对的。但若反过来写 SDIFF tag:ai tag:java，结果是空集（因为 SDIFF 总是以第一个 key 为基准，减去后面所有集合的并集）。
真实场景中容易踩坑的是嵌套排除，比如「Java + Spring 但排除实习岗、排除远程岗」：
- 错误写法：
SDIFF tag:java tag:spring tag:intern tag:remote→ 语法非法，SDIFF只接受一个 base key - 正确链式写法：
SDIFF temp:java-spring tag:intern tag:remote，其中temp:java-spring已通过SINTERSTORE构建 - 更稳妥的方式：用 Lua 脚本封装，避免客户端多次往返和状态丢失
Redis 7.0 的 EVAL 支持 redis.call('SDIFF', ...)，能在一个原子上下文中完成多步差集，且不受网络中断影响。
底层编码切换会影响内存与速度，但你通常不用管
Redis Set 在元素全是整数且 ≤512 个时，自动用 intset 编码（紧凑数组）；超过阈值或含字符串，立刻切到 hashtable（Dict）。这个过程完全透明，但有两点必须知道：
- 如果你存的是文章 ID（如
"art:12345"），哪怕全是数字字符串，也进不了intset—— 因为intset只认纯整型（12345，不带引号、不带前缀） -
hashtable占内存明显更高：10 万个字符串 ID，在hashtable下约占 8MB；同样数据若能走intset，可能仅 1.2MB - 别试图用
DEBUG OBJECT key监控编码——该命令在生产禁用，且 Redis 7.0 默认关闭debug权限
真正该盯的是 INFO memory 中的 used_memory_dataset_perc，如果长期 >95%，说明集合碎片或冗余数据太多，该清理冷标签了。
