默认参数下redis-cli --bigkeys会高频扫描阻塞主线程，生产环境必须加-i控制节奏、用--memkeys按真实内存排序，且需配合MEMORY USAGE SAMPLES 100~500精准测内存，避免因大Key过期集中引发缓存击穿与双重雪崩。
redis-cli --bigkeys 扫描时为什么不能直接用默认参数？
默认不加 -i 和 --memkeys 会阻塞主线程，尤其在大实例上可能卡住几秒甚至更久。生产环境必须控制扫描节奏：redis-cli --bigkeys -i 0.01 表示每处理 100 个 key 就 sleep 10ms，避免打挂主从；--memkeys（Redis 7.0+）才能按真实内存排序，而 --bigkeys 只取每种类型“元素数最多”的那个 key，容易漏掉体积型大 Key（比如一个只有 2000 个 field 但每个 value 是 2MB 的 hash）。
MEMORY USAGE 命令怎么用才准？SAMPLES 参数影响有多大？
MEMORY USAGE 是唯一能确认真实内存占用的命令，但对集合类型必须配 SAMPLES，否则返回的是估算值（且不准）。例如：redis-cli MEMORYUSAGE "order:cache:2024" SAMPLES 100——对一个含 800 万 field 的 hash，采样 100 个 field 就能较准确推算总内存；采样太少（如 10）误差可能超 30%，采样太多（如 10000）又拖慢命令本身。实测中，hash/zset 类型给 SAMPLES 100~500 是平衡精度与开销的合理区间。
过期策略和缓存击穿之间到底什么关系？
BigKey 本身不会直接导致击穿，但它的过期行为会放大击穿风险：TTL 设为相同时间点（比如全设成 EXPIRE key 3600），一旦这个 key 过期，所有请求同时穿透到 DB；更糟的是，如果这个 key 是个大 hash，DEL 操作本身就会阻塞主线程几百毫秒，期间新请求无法读缓存、也无法写缓存，等于双重雪崩。所以必须做到两点：
- 分散过期时间：在业务层写入时加随机偏移，比如
EXPIRE key (3600 + random(0, 600)) - 禁用永不过期：对任何可能膨胀的 key（如日志类 list、粉丝列表 hash），必须设 TTL，哪怕只是 24 小时
UNLINK 比 DEL 安全，但什么时候它也救不了场？
UNLINK 能把删除操作异步化，适合大多数场景，但它只解决“释放内存”这一步。如果 BigKey 正在被高频访问（比如每秒上千次 HGETALL），主线程仍要同步序列化整个结构发给客户端，网络 IO 和 CPU 都扛不住。此时 UNLINK 无效，必须前置治理：拆分（user:1001:fans:001 ~ :010）、压缩（用 zstd 压缩 value）、或换存储（粉丝 ID 改存 ClickHouse）。真正难处理的从来不是删不掉，而是删了之后业务逻辑还依赖它一次性读全。
