这个坑值得记一笔。业务偶发几百毫秒的卡顿，监控显示瞬时流量并不高，排查发现某个键存了几十万个元素。
这类报错背后常见的原因有几处，逐个排除就行。业务把列表当队列用，只写不清理；缓存整个大对象，没有做分片；定时任务一次性写入大批数据。
扫描实例里的大键
redis-cli --bigkeys随后看单个键的类型和长度
redis-cli memory usage 键名评估拆分方案
redis-cli object encoding 键名末了用分批方式重建该键
redis-cli --scan --pattern 'prefix:*' | head排查用的命令都是临时敲的，没有写成脚本，事后才整理。
手上没有现成的复现脚本，就照着线上请求手工拼了一个。
报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
改完先别撤，确认这几项。大键拆分后单次读取耗时降到毫秒级，实例卡顿消失。
容易忽略的是，删除大键本身也会阻塞，用异步删除或者在低峰处理；命令行扫描要控制频率，别把生产实例压垮。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。