Redis 8.10 SUNIONCARD 为什么不返回成员：集合并集计数的低开销用法

做标签去重、受众圈选或多来源权限统计时，业务经常只需要“合并后有多少个不同成员”。如果先调用 SUNION，Redis 会把成员集合交给客户端，应用层再数长度；成员很多时，网络和客户端内存都被明细拖住。Redis 8.10 新增的 SUNIONCARD 把结果收敛成一个整数，适合把“只要总数”的请求留在 Redis 内部完成。

从成员列表变慢开始：问题边界是“只要总数”

故障现场通常不是 Redis 报错，而是接口响应体突然变大：两个受众集合各有几十万成员，接口却只需要展示“覆盖用户数”。这时 SUNION key1 key2 的返回值是去重后的成员列表，客户端还要遍历一次才能得到数量。

先把需求分成两类：需要导出成员、继续对成员做业务判断时，保留 SUNION；只需要一个去重后的数量时，改用 SUNIONCARD。它不写入新键，也不改变源集合，返回值就是一个整数。

Redis 8.10 的计数路径：SUNIONCARD 与 SUNION 的分工

SUNIONCARD 的基本语法是：

SUNIONCARD numkeys key [key ...]

numkeys 表示后面紧跟的集合键数量。例如 key1 有 a、b、c，key2 有 c、d、e：

SUNIONCARD 2 key1 key2
(integer) 5

重复的 c 只计一次；不存在的键按空集合处理。这里最容易写错的是数字：写成 3 却只传两个键，会让参数边界失配。与 SUNION 相比，计数路径不需要把五个成员返回给调用方。

LIMIT 和 APPROX 怎么决定：精确、截断与估算

默认模式是精确基数。需要“超过某个规模就够了”时，可以加 LIMIT：

SUNIONCARD 2 key1 key2 LIMIT 3
(integer) 3

当真实并集达到 3，Redis 可以停止继续计数并返回 3；LIMIT 0 表示不设上限。这个值适合分页开关、风控阈值和容量告警，但不能被报表误读为真实总数。

APPROX 则是另一种取舍：Redis 使用 HyperLogLog 估算基数，官方文档给出的标准误差约为 0.81%，适合超大集合且业务能接受小误差的看板。这里可以把默认模式称为精确计数，把带 APPROX 的结果称为近似计数；若要做财务结算或精确配额，别为了少一点计算就打开它。

上线前的集群检查：多键路由与回滚

SUNIONCARD 从 Redis Open Source 8.10.0 开始提供，命令文档还标注了 @read、@set、@slow ACL 分类。升级前先看服务端版本和 ACL，不要只看客户端是否能补全命令。

Redis Cluster 环境要单独检查多键操作规则。key1 和 key2 如果不满足同槽要求，调用可能遇到路由限制；单机测试得到 5，并不能证明生产集群一定能按同样方式执行。灰度阶段可以保留旧的 SUNION 路径作为回退，但只有在确实需要成员时才把明细拉回客户端。

常见问题

SUNIONCARD 会返回并集成员吗？

不会。它只返回并集的基数，也就是去重成员数量；需要成员明细仍应使用 SUNION。

LIMIT 3 代表真实并集只有 3 个吗？

不一定。它表示计数达到 3 后可以提前停止，所以返回 3 只能说明结果至少达到阈值。

APPROX 能替代所有精确统计吗？

不能。它面向能容忍小误差的大规模统计；结算、配额和审计类指标应继续使用默认精确模式。

把调用改成 SUNIONCARD 前，先问一句“调用方是否真的需要成员”。答案为否，再核对版本、键数量、Cluster 路由和指标口径，通常就能把一次不必要的明细搬运收回到 Redis 内部。