redis响应变慢90%以上源于客户端，需用aop拦截redistemplate.execute()分三段计时（连接获取、序列化、命令执行），按命令类型分级设阈值（如get/set为20ms、scan为500ms），并针对lettuce异步特性谨慎调用future.get()测真实耗时。
Spring Boot应用里Redis响应变慢，90%以上不是Redis服务端卡了，而是客户端在处理大Key时被拖慢——尤其是序列化、反序列化、网络传输和主线程阻塞这四块。直接看redis-cli --latency或慢日志没用，得进应用进程里抓真实耗时。
用AOP拦截RedisTemplate.execute()分段测时
所有opsForValue().get()、boundHashOps().hgetall()最终都落到execute()，拦这里覆盖全、无遗漏。别拦executeWithStickyConnection()，集群模式才用，普通项目基本不涉及。
- 连接获取耗时高 → 说明
lettuce.pool.max-idle太小，或连接泄漏未释放 - 序列化耗时高 → 大概率用了
JdkSerializationRedisSerializer，换GenericJackson2JsonRedisSerializer可降80%+序列化时间 - 命令执行耗时高 → 才是纯Redis + 网络往返时间，这时候再查
MEMORY USAGE或--bigkeys
按命令类型设动态阈值，避免误报
固定阈值（如>100ms）会把SCAN扫百万key当成“异常”，但这是合理行为；而GET耗50ms就极可疑。必须分级：
-
GET/SET/DEL类单key操作：阈值设20ms -
HGETALL/LRANGE类批量操作：阈值设100ms -
SCAN/SUNION类扫描/聚合操作：阈值设500ms，且日志加isScan:true标记
超时日志只打ERROR级，且必须带if (duration > threshold)条件判断，否则日志刷爆。
生产环境慎用future.get()测Lettuce真实耗时
Lettuce默认异步提交，execute()返回的是Future，AOP拦到的只是“任务提交”时间，不是真正执行完的时间。要测准，得调future.get(timeout, TimeUnit)，但这会阻塞线程。
- 开发/测试环境可全量启用
- 生产环境建议仅对慢日志采样启用（比如每1000次记录1次）
- 别在切面里无条件
get()，否则可能把线程池拖垮
定位到大Key后，优先验证是否真由它导致延迟
别急着删或拆，先确认它是不是“高频访问+大体积”的组合：
- 用
redis-cli -h $host -p $port --bigkeys -i 0.01快速扫出分布，看有没有String >10KB 或 Hash元素 >5000 - 对疑似Key执行
MEMORY USAGE <key></key>，确认内存占用（注意：List/Set等结构返回的是估算值） - 查慢日志：
SLOWLOG GET 10，看HGETALL、DEL是否频繁出现在前几行 - 关键点：如果这个Key访问QPS很低（比如每天几次），即使它有50MB也不影响性能——大Key的危害只在“高频+大体积”时爆发
