redis单个string超10mb必须拆分，建议512kb内切片并用getrange/setrange操作；bighash应按访问频次和语义拆为小hash，禁用hgetall；一致性靠lua脚本或状态字段+重试保障。
BigString 超过 10MB 就该拆，别硬扛
Redis 单个 STRING 值超过 10MB 时，GET/SET 延迟明显上升，主从同步卡顿、AOF rewrite 阻塞、RDB fork 失败风险陡增。这不是“建议优化”，是实际运行中会触发 OOM command not allowed when used memory > 'maxmemory' 或 Timeout waiting for response from master 的临界点。
拆法很简单：按固定长度切片，加序号后缀存成多个 key：
SET user:1001:profile:0 "{'name':'Alice','bio':'..."
SET user:1001:profile:1 "...','avatar':'https://...'}"
关键点：
- 切片长度建议控制在 512KB 以内（避开 Redis 网络缓冲区默认大小）
- 必须用
GETRANGE/SETRANGE配合业务逻辑做读写，不能直接GET全量再拼接——否则又回到大 Key 场景 - 删除时得用
DEL user:1001:profile:0 user:1001:profile:1 ...，别漏掉；推荐用 Lua 脚本原子执行 - 如果业务需要原子读全量，不要在客户端拼，改用服务端 Lua +
redis.call('GET', ...)拼接并返回，避免网络多次往返
Hash 拆分不能只靠 hscan，得重设计键结构
一个 HASH 有 50 万个 field，HGETALL 基本不可用，HSCAN 游标也可能超时或返回不完整。这时不是“加个游标参数就能解决”，而是原始建模出了问题。
正确做法是把“单个大 Hash”转为“多个语义化小 Hash”，例如：
HSET user:1001:profile:name "Alice"
HSET user:1001:profile:contact "{'email':'a@b.c','phone':'138...'}"
HSET user:1001:settings:notify "{'mail':true,'sms':false}"
要点：
- 拆分依据是访问频次和聚合粒度——高频读写的字段单独成 Hash，低频/大体积字段（如 JSON blob）单独切片
- 避免用
user:1001:profile:0、user:1001:profile:1这种无意义编号，后续维护和 debug 成本极高 -
HLEN和HEXISTS在拆分后依然有效，但HGETALL必须变成多次HGET或批量HMGET，别指望兼容旧接口 - 如果原来依赖
HINCRBY做计数，拆分后需确保计数字段落在同一子 Hash 内，否则无法原子更新
拆分后一致性怎么保？别信“先删后写”
BigString 或 BigHash 拆成多 key 后，写入不再是原子操作。比如更新用户资料，要同时写 user:1001:profile:name、user:1001:profile:contact、user:1001:settings:notify —— 中间失败会导致数据不一致。
可靠方案只有两个：
- 用 Lua 脚本封装全部写操作，通过
EVAL保证原子性（注意脚本总执行时间别超 100ms，否则阻塞其他命令） - 业务层引入状态字段 + 重试机制：先写新 key，再设
user:1001:profile:status为updating，全部成功后改为active；读取时若遇updating，回退到旧 key 或等待重试 - 绝对不要用
DEL所有旧 key 再SET新 key —— 删除和写入之间存在明显窗口期，缓存穿透风险极高
如何发现还没拆但已经危险的大 Key？别只看 info memory
INFO memory 只告诉你用了多少内存，看不出哪个 key 是罪魁祸首。真正有用的是：
-
redis-cli --bigkeys：扫描样本，报告 top 5 大 key 类型和 size，但只采样，可能漏掉冷 key -
redis-cli --hotkeys：识别高访问 key，但不反映体积 - 更准的做法是开启
CONFIG SET notify-keyspace-events KEA，配合监听__keyevent@0__:set事件，在应用写入时记录 key 大小（用STRLEN/HLEN/SCARD等），上报到监控系统 - 线上禁止用
MEMORY USAGE全量扫 key —— 它会阻塞主线程，尤其对大 key 本身就会卡住几秒
最常被忽略的一点：拆分不是一劳永逸。当业务增长使某个子 key 再次膨胀（比如 user:1001:logs 每天追加，半年后又成 BigString），得有自动检测 + 动态再切分的机制，而不是等报警才人工介入。
