确认慢指令拖垮Redis应直接查slowlog而非猜测；默认阈值10000微秒（10ms）在低延迟场景下过宽松，需结合基线延迟（如--intrinsic-latency测得90μs）判断实际“慢”命令，再用SLOWLOG GET查看耗时字段（微秒）及客户端信息，辅以MEMORY USAGE和SCAN定位大key。
怎么确认是慢指令拖垮了Redis
直接看 slowlog，不是猜。Redis 默认只记录执行时间超过 slowlog-log-slower-than 10000（即10ms）的命令，这个阈值在高负载或低配环境里可能太宽松——比如基线延迟只有80微秒时，200微秒的命令就已经是2.5倍了，但不会进 slowlog。
先用 redis-cli --intrinsic-latency 120 测基线，再对比运行时延迟。如果某次 GET 耗时 300 微秒，而基线是 90 微秒，那它就是“慢”，哪怕没进 slowlog。
- 查当前慢日志条数：
redis-cli slowlog len - 取最近 5 条：
redis-cli slowlog get 5，注意第三字段是耗时（微秒），第四字段是客户端地址 - 别依赖
INFO stats的instantaneous_ops_per_sec平均值——它会掩盖毛刺
哪些命令最容易引发连锁阻塞
Redis 单线程模型意味着一个 O(N) 命令卡住，后面所有请求都得排队。最危险的不是 KEYS * 这种明显坏操作，而是看似无害、但在大 Key 上执行的命令。
-
HGETALL large_hash_key：如果这个 hash 有 50 万 field，实际是 O(N)，不是 O(1) -
LRANGE big_list 0 -1：全量拉取 list，内存+网络双开销 -
SUNION key1 key2 key3：集合越大，合并越慢，且结果集可能远超单个 key -
DEL huge_sorted_set：删除带几百万 member 的 zset，释放内存和重建跳表都耗时
特别注意：EXPIRE 和 DEL 对大 Key 同样危险——过期 key 清理不是惰性的，被动访问触发时才真正释放内存。
如何快速定位具体是哪个 Key 在拖慢服务
slowlog 只给命令和参数，不告诉你这个 key 实际有多大。得配合 MEMORY USAGE 和 SCAN 主动探查。
- 从 slowlog 中提取可疑 key 名，执行
MEMORY USAGE key_name看真实内存占用（单位字节）；超过 10KB 就算大 Key - 用
SCAN遍历，配合TYPE和STRLEN/LLEN/HLEN批量筛查：redis-cli --scan --pattern "user:*" | xargs -L1 redis-cli type - 避免用
KEYS user:*—— 它本身就会阻塞，且无法中断 - 对疑似大 Hash，用
HSCAN key 0 COUNT 100分批检查 field 数量，比HLEN更安全（不会一次性加载全部）
修复时别只想着删，得考虑业务连续性
直接 DEL 一个 200MB 的 key，可能让 Redis 卡住 2 秒以上，下游全部超时。更稳妥的做法是渐进式清理或结构拆分。
- 用
UNLINK替代DEL：它把释放内存的操作交给后台线程，主线程只做逻辑删除 - 对大 List/Hash，改用分片 key：比如
user:123:profile:0~user:123:profile:9，每次只操作一个分片 - 用 Lua 脚本控制删除节奏：
EVAL "for i=1,100 do redis.call('LPOP', KEYS[1]) end" 1 big_list，每次只弹出 100 个元素 - 如果必须保留全量数据，考虑迁移到其他存储（如 SSDB 或本地文件），Redis 只存热字段
真正容易被忽略的是：慢指令的影响不只在 Redis 侧。一次 500ms 的 SUNION，会让上游应用的连接池等待、重试、甚至触发熔断——排查时一定得顺着调用链往客户端看，不能只盯着 redis-cli 的输出。
