Redis位图稀疏时内存暴增因SETBIT按字节对齐整块分配，设第100万bit即分配125KB并填充零字节；分段存储可缓解但需手动路由且不支持跨段BITOP。
因为 SETBIT 不是“只存你设的那一位”，而是按字节对齐、整块 malloc —— 设第 100 万 bit，Redis 就会分配 125001 字节（1000000 ÷ 8 + 1），中间全填 0，不管其他位有没有值。
SETBIT 的内存分配是刚性的，不是稀疏的
Redis 的 Bitmap 底层就是 string 类型（raw 或 embstr），没有稀疏结构支持。它不区分“用了哪几个 bit”，只看最大 offset：
- 调用
SETBIT user:active 9999999 1→ 计算需12499999 ÷ 8 + 1 = 12500000字节 ≈ 12.5MB - 哪怕你之前只设过 3 个 offset（比如 0、1、9999999），这 12.5MB 也照常分配并驻留
- 如果业务用用户 ID 当 offset，而 ID 是 64 位 Long（如 1234567890123），那直接触发
2^32上限溢出或分配 256MB+ 内存
为什么 BITCOUNT/BITPOS 会变慢，甚至拖垮 CPU 缓存
这些命令必须遍历整块已分配内存，无法跳过全零区域：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
BITCOUNT对 125MB 字符串做 popcount，哪怕里面只有 1 个 1，也要扫完全部 -
BITPOS key 1在稀疏场景下平均要扫描到末尾才命中，缓存行大量失效 - RDB/AOF 持久化时，这 125MB 的零字节全写盘，备份体积虚高、恢复慢
集群环境下还会放大问题：单 key 热点 + slot 倾斜
所有操作都打到同一个 key，意味着打到同一个 Redis 实例的同一个 slot：
- 无法利用集群横向扩展能力，QPS 上不去，CPU 和内存双爆
- 迁移或扩缩容时，这个大 key 会卡住整个 slot 迁移流程
-
SCAN "user:active*"效率极低，而KEYS直接阻塞主线程
分段存储不是自动的，路由和兜底都得自己写
把 user:active 拆成 user:active:seg:0、user:active:seg:1… 只是开始：
- 段长选太小（如 100）→ key 数爆炸，
EXPIRE、DEL、SCAN压力陡增 - 段长选太大（如 50 万）→ 单段仍可能吃掉上百 MB，没解决根本问题
-
BITOP不跨段，想算交集？得在应用层GET多段二进制串，用&运算合并 - 某段 key 不存在时，
GET返回nil，但BITCOUNT遇nil直接报错，必须先EXISTS
真正容易被忽略的，是业务是否真的需要“任意 offset 的精确 bit 操作”——比如统计“过去三年每天登录”，用 Bitmap 存 1095 位没问题；但存“所有用户 ID 是否参与”，ID 稀疏又带长尾，就该换时间序列或布隆过滤器（接受误差）或分库分表式标记。
