SINTERCARD比SINTER+SCARD更快，因其在服务端直接计数交集大小，不传输完整集合数据，避免网络开销与内存占用；Redis 7.0内部跳过构造set，采用哈希表遍历或跳表扫描优化。
为什么SINTERCARD比SINTER + SCARD更快？
直接用 SINTER 拿出所有共同元素再算长度，会把完整交集数据从 Redis 传输到客户端，网络开销大、内存占用高，尤其当两个好友集合各含数万成员时，可能卡顿甚至 OOM。而 SINTERCARD 是服务端原生聚合命令，只返回一个整数结果，不传输中间集合，CPU 和带宽都省了。
它本质是「交集计数」的原子优化，不是语法糖 —— Redis 7.0 内部跳过了构造完整 set 的步骤，用哈希表遍历+位图优化（对小集合）或跳表交集扫描（对大集合）来直接计数。
SINTERCARD 的基本用法和参数陷阱
命令格式：SINTERCARD numkeys key [key ...] [LIMIT limit]。注意两个易错点：
-
numkeys必须显式传入，不能省略 —— 即使你只想算两个集合交集，也得写SINTERCARD 2 user:123:friends user:456:friends，少写这个数字会报ERR wrong number of arguments for 'sintercard' command -
LIMIT是可选但关键的性能开关：设为LIMIT 100表示“只要交集数量 ≥100 就提前返回 100”，适合做阈值判断（比如“是否互为潜在高重合度好友”），避免在超大交集上浪费时间
和 SINTER 对比的实际耗时差异（实测场景）
在 Redis 7.0（单核 2.4GHz，集合平均 5w 元素）下测试两个用户好友交集：
# 方式一：SINTER + 客户端计数（Python）
redis.sinter("user:1001:friends", "user:1002:friends") # 返回 48217 个 ID，耗时 ~180ms
len(result) # 再加 2ms
<h1>方式二：SINTERCARD（同等条件）</h1><p>redis.sintercard(2, "user:1001:friends", "user:1002:friends") # 直接返回 48217，耗时 ~9ms</p>差距主要来自：前者需序列化/网络传输/反序列化约 2MB 数据；后者只走一次轻量协议交互。如果加 LIMIT 100，耗时还能压到 1ms 内 —— 因为 Redis 在内部计数达到 100 后立刻中断扫描。
在业务逻辑中安全嵌入 SINTERCARD 的注意事项
它不改变数据，但要注意边界情况：
- 任意一个 key 不存在，结果为 0（不是报错），符合集合论定义，但你要确认这是否符合业务预期（比如“用户无好友列表”是否该参与计算）
- key 类型错误（如误传了 string）会报
WRONGTYPE Operation against a key holding the wrong kind of value，建议上游调用前用TYPE或 pipeline 做轻量校验 - 集群模式下，所有 key 必须落在同一个 slot —— 如果 key 名没带
{...}hash tag，且分属不同节点，会报CROSSSLOT Keys in request don't hash to the same slot
真正容易被忽略的是 LIMIT 的语义：它不是“取前 N 个再计数”，而是“计数过程中一旦达到 N 就截断并返回 N”。这意味着你无法用它精确判断“交集是否恰好等于 50”，只能用于“是否 ≥50”这类存在性判断。
