记录一下那天晚上的排查过程。Redis 6.2 的实例里有个几十万元素的 list，执行 del 之后整个实例卡了两秒，监控上延迟毛刺明显，客户端报 read timeout。
刚开始盯着「这个 key 还在被定时任务反复重建，每次删除都要卡一下」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。del 是同步释放，几十万元素的对象要在主线程里逐块归还内存。少数情况下是lazyfree-lazy-user-del 没开，del 不会走异步释放。
另外，从库上也在同步删除，主从延迟被一起拖高。
动手时先找出体积异常的 key
redis-cli --bigkeys再往下打开异步删除相关开关
redis-cli config set lazyfree-lazy-user-del yes && redis-cli config set lazyfree-lazy-expire yes随后用 unlink 替代 del 做验证
redis-cli unlink big:list:20240101等前面都确认过，再把配置写进文件防止重启失效
printf 'lazyfree-lazy-user-del yes\nlazyfree-lazy-expire yes\n' >> /etc/redis.conf别只看报错消失，验证要多做一步。再删同样大小的 key 时 redis-cli 立即返回，延迟监控上没有秒级毛刺，used_memory 在几秒内平滑回落。
unlink 只是把释放挪到后台线程，内存不会立刻降；业务上更该做的是拆 key，避免单个对象大到几 MB。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。