SINTER在大用户量下变慢是因为其同步阻塞、O(N×M)时间复杂度及全量内存扫描；应结合存在性检查、分场景使用SINTERSTORE、区分大小号策略并统一key命名。
直接用 SINTER 就能拿到共同好友，但实际线上跑起来容易卡顿、超时或返回空——问题不在命令本身，而在 key 设计、数据规模和调用方式。
为什么 SINTER 在大用户量下会变慢？
Redis 的 SINTER 是同步阻塞操作，时间复杂度为 O(N×M)，其中 N、M 分别是两个集合的元素数量。当 friend_10001 有 50 万好友、friend_10002 有 40 万时，交集计算可能耗时数百毫秒，甚至触发客户端超时。
- 单次
SINTER不会自动分片或限流，全量内存扫描不可避免 - 如果两个 key 都落在同一 Redis 实例上，高并发请求会争抢 CPU 和内存带宽
-
SMEMBERS+ 应用层求交这种“绕路方案”更糟——它把数据全拉到应用内存，OOM 风险陡增
SINTERSTORE 要不要用？
用，但只在特定场景：需要高频复用结果（比如共同好友数要展示在首页）、且能接受几秒延迟更新。它把结果存成新 key，后续读取变成 SCARD 或 SRANDMEMBER，O(1) 响应。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 写入时仍需完整计算，但可异步触发：
SINTERSTORE temp_common_10001_10002 friend_10001 friend_10002 - 记得加过期时间：
EXPIRE temp_common_10001_10002 3600，避免缓存堆积 - 不要用
SINTERSTORE替代实时查询——它不反映秒级变化的好友关系
如何避免查不到共同好友？
常见原因是 key 不存在或为空集合，SINTER 默认返回空列表，不会报错，容易被当成“没共同好友”而忽略数据缺失。
- 先用
EXISTS friend_10001和EXISTS friend_10002确认 key 存在 - 再用
SCARD friend_10001和SCARD friend_10002判断是否为空（返回 0 表示无好友） - 若任一集合为空，直接短路返回空数组，跳过
SINTER - 注意：
SISMEMBER不能替代存在性检查——key 不存在时它也返回 0，和“存在但不含该 member”无法区分
小号用户 vs 大 V 用户的交集策略差异
对普通用户（SINTER 安全；对大 V（>10 万关注者），必须降级或预计算。
- 小号：直接
SINTER friend_u1 friend_u2，响应稳定在 1–5ms - 大 V：改用「粉丝交集」思路——如果 u1 是大 V，查
u2的好友中哪些在u1的粉丝集合里（follow_u1），用SISMEMBER follow_u1 u2_id批量判断 - 更稳的做法：提前用
SDIFFSTORE+SINTERSTORE维护“高频共同好友对”，例如按周跑一次定时任务，只算活跃用户间的交集
真正容易被忽略的是 key 命名一致性——friend_10001 和 follow_10001 混用、大小写不统一、用户 ID 类型（int/string）不一致，会导致交集永远为空，而日志里根本看不出问题。
