缓存命中率持续偏低（如长期低于30%）、key频繁消失、数据库QPS居高不下，表明缓存未有效挡流量；需用ttl批量验证实际剩余时间，排查TTL被覆盖、单位混淆、中间件默认策略及内存淘汰（evicted_keys上涨）等根因，并匹配数据变更频率合理设置TTL。
缓存有效期过短，最直接的表现是：缓存命中率持续偏低（比如长期低于30%），Redis里key频繁“刚存进去就没了”，数据库QPS却居高不下——这说明缓存没真正起到“挡流量”的作用。
看真实存活时间：用ttl批量验证
别只信代码里写的“expire=3600”，得看它在Redis里实际还剩多少秒：
- 挑5～8个高频访问的key（如user:1001、product:2056），逐个执行ttl key_name
- 如果多数返回值集中在几十秒到一两分钟，远低于预期，说明TTL被意外覆盖或重设
- 注意返回-2（key不存在）和-1（永不过期）——前者可能是写入失败，后者需确认是否真该永存
查写入源头：哪些地方在设过期时间
同一个key可能在多处被set，后写的会覆盖前写的。重点排查：
- 项目中所有setex、expire、@Cacheable(expire = ...)调用点
- 是否混用了不同单位？比如Java里用TimeUnit.SECONDS，Go里误传毫秒值，导致实际只存了1秒
- 是否有中间件或代理层（如Twemproxy、Redisson）自动加了默认TTL？
盯配置与运行时行为：内存压力会偷偷改命
即使代码写了3600秒，Redis也可能不认账：
- 执行config get maxmemory和config get maxmemory-policy，确认是否启用了allkeys-lru或volatile-lru——内存不足时，它会提前淘汰key，跟TTL无关
- 查info stats里的evicted_keys，如果这个值持续上涨，说明缓存正被“强制清退”，不是过期，是被挤走的
- 检查应用日志里是否有"OOM command not allowed"或"MISCONF Redis is configured to save RDB snapshots"类报错，这类异常可能导致set命令静默失败
对比业务节奏：有效期要匹配数据变化频率
缓存不是越长越好，但也不能比数据更新还快：
- 用户资料类数据，若后台每5分钟同步一次，缓存设60秒就纯属摆设
- 商品价格类数据，若实时变更，硬设30分钟TTL反而引发一致性问题；不如设短些（如2分钟），配合主动刷新机制
- 可简单估算：合理TTL ≈ 数据平均变更间隔 × 0.7（留出缓冲，避免刚更新就失效）
