先用 redis-cli --bigkeys 初筛，再用 memory usage 精准定位大key；hash类需抽样 hgetall 查value长度；拆键优先按语义而非字段数；删大key须用 unlink 异步执行，并监控 used_memory_peak、mem_fragmentation_ratio、evicted_keys 三指标。
大Key导致Redis内存爆满，怎么快速定位？
先别急着删数据，90%的爆内存问题都卡在没看清到底是谁占了空间。用 redis-cli --bigkeys 只能发现“类型最大”，但对 HASH 这类结构，它只报键名和字段数，不报总内存占用——字段多≠内存大，字段里存了1MB的JSON才真要命。
更准的做法是结合 MEMORY USAGE 手动查可疑键：
redis-cli MEMORY USAGE "user:profile:10086"
常见陷阱：
-
SCAN遍历全库再逐个MEMORY USAGE会阻塞主线程，线上慎用；建议在从节点或低峰期执行 - Python 应用里用
redis-py调用时，别用pipeline批量发MEMORY USAGE，Redis 6.0+ 才支持该命令 pipeline，老版本直接报错ERR unknown command `MEMORY` - Hash 类型的“大”往往来自少数几个超长
field（比如存了 base64 图片），HLEN看不出问题，得用HGETALL抽样看 value 长度
Hash结构拆分：按业务维度还是固定长度？
直接把一个 user:profile:10086 拆成 user:profile:10086:base、user:profile:10086:setting 是最常用做法，但关键在“拆的边界是否稳定”。如果业务上“用户设置”字段未来可能膨胀到200个，那按功能拆就比按字段数拆更可持续。
实操建议：
- 优先按语义拆：把高频读写、生命周期不同、变更频率差异大的字段分到不同 Hash 键，比如
user:meta:10086（注册时间、最后登录IP）和user:cache:10086（临时token、未读消息数）分开 - 避免按固定字段数硬拆（如每10个 field 一个子键），会导致跨键事务难做、客户端逻辑碎片化
- 拆完必须改客户端：原
hgetall("user:profile:10086")得变成并发请求多个键，用asyncio.gather或线程池，别串行调用 - 保留旧键做迁移过渡：加一层 Python 代理逻辑，读时 fallback 到旧键，写时双写，等流量切完再下线
热Key打挂Redis，为什么不能直接DEL？
DEL 删除大 Key（尤其含几万 field 的 Hash）会阻塞 Redis 主线程，时间 = O(N)，期间所有命令排队，监控上看就是 latency 突增、连接超时。这不是“慢”，是“停摆”。
正确姿势是 UNLINK + 异步清理：
-
UNLINK立即返回，把释放内存的动作交给后台线程，Redis 4.0+ 支持，Python 用redis-py3.0+ 可直接调r.unlink("key_name") - 但注意：
UNLINK不保证立即释放内存，INFO memory中mem_allocator和used_memory_rss可能延迟数秒才降，别删完立刻查监控断定失败 - 热Key 不能只靠删，得压请求：在 Python 层加本地缓存（如
functools.lru_cache或diskcache），对同一user_id的 profile 查询做毫秒级缓存，避开重复打 Redis - 别在 Web 请求里同步调
unlink—— 即使不阻塞 Redis，Python 的 redis-py 默认同步 I/O 也会拖慢响应；应丢进 Celery 或asyncio.to_thread异步执行
异步 unlink 后，怎么确认内存真释放了？
看 used_memory 不够，得盯三个指标：
-
used_memory_peak：峰值内存，如果它没降，说明旧内存块还没被 malloc 回收（jemalloc 延迟释放常见） -
mem_fragmentation_ratio：大于 1.5 就说明内存碎片高，UNLINK后碎片可能更高，需后续执行MEMORY PURGE（Redis 6.0+）或重启实例 -
evicted_keys：如果删完还在涨，说明淘汰策略仍在生效，得检查maxmemory-policy是否设成了noeviction以外的值，避免误伤其他键
Python 侧可写个轻量巡检脚本，定时取 INFO memory 解析，重点告警 used_memory > 0.8 * maxmemory 且 mem_fragmentation_ratio > 1.7 的实例——这种组合大概率是 unlink 没起效或碎片卡死。
真正麻烦的不是技术动作，是拆键和 unlink 的时机判断：大 Key 拆分必须等业务低峰，而热Key的 unlink 必须在监控发现延迟突增后 30 秒内触发，晚了可能已引发雪崩。这两件事没法全自动，得靠人盯住指标+预案。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
