sql结果缓存需分层设计：高频只读数据用长ttl，主键查询按key失效，聚合查询禁直接缓存，实时数据走强一致性；失效策略以写时失效为主、读时校验为辅，避免纯ttl；key须语义化、带业务前缀与参数签名；需监控命中率、熔断降级及僵尸缓存清理。
SQL结果缓存不是简单地把查询结果扔进Redis就完事，关键在于缓存什么、什么时候失效、谁来负责更新、怎么避免脏数据。策略选错，缓存反而成为系统瓶颈或数据不一致的源头。
按查询特征分层缓存
不是所有SQL都适合缓存，应按读写比例、数据变动频率、结果集大小做分级：
- 高频只读+低更新率（如：城市列表、配置项）→ 用长 TTL（1小时以上），支持主动刷新或监听配置变更事件
- 中频查询+业务主键明确（如：SELECT * FROM user WHERE id = ?）→ 按主键构建缓存Key（user:123），配合DB写操作后删除对应Key
- 带参数聚合/范围查询（如：SELECT COUNT(*) FROM order WHERE status=1 AND created_at > '2024-01-01'）→ 不建议直接缓存结果，可缓存物化视图或预计算指标，或改用布隆过滤+局部缓存组合
- 实时性要求高（如：账户余额、库存）→ 禁用结果缓存，走强一致性读，或用Cache-Aside + 分布式锁保障单次重建
失效策略比缓存策略更重要
缓存失效设计不当是脏数据主因。推荐组合使用以下方式：
- 写时失效（Write-Invalidate）为主：UPDATE/INSERT/DELETE 后立即 DEL 缓存Key；注意事务边界——必须在DB事务提交后触发，否则可能删掉尚未生效的新数据
- 读时校验（Read-Through + Version Check）为辅：缓存中存数据版本号（如MySQL的UPDATE_TIME或自增version字段），读取时比对DB最新版本，不一致则异步刷新
- 避免纯超时驱逐（TTL）作为唯一机制：尤其在热点数据场景下，TTL到期集中回源易打垮DB；可叠加随机偏移（TTL ± 5%）缓解雪崩
Key设计要兼顾可读性与隔离性
缓存Key不是SQL哈希值，而是语义化+可管理的标识：
- 包含业务域前缀（如 order:list:status:paid）、关键参数签名（如 md5("2024-01-01,2024-01-31")），不拼接原始SQL（含空格、大小写、注释差异）
- 区分租户/环境：多租户系统需加入tenant_id；测试环境加test_前缀，避免误刷生产缓存
- 对分页查询，将page和size纳入Key（如 user:list:dept:tech:page:2:size:20），而非只缓存第一页
- 敏感字段脱敏处理：用户手机号、身份证等不可出现在Key明文中，可用ID替代
监控与兜底不能少
上线后必须可观测，否则缓存问题难以定位：
- 记录每类查询的缓存命中率、平均RT、回源错误码分布，命中率持续低于70%需重新评估缓存价值
- 对高风险查询（如订单详情）设置熔断开关：当连续5次回源失败，自动降级为直连DB，并告警
- 定期扫描缓存Key存活状态，识别长期未访问或超期未更新的“僵尸缓存”，防止内存泄漏或误用过期数据
- 提供运维命令行工具，支持按业务维度批量清理（如 flushall --domain=user --env=prod）
缓存不是银弹，而是权衡的艺术。真正稳定的SQL缓存系统，80%功夫花在失效逻辑、Key治理和可观测性上，而不是存得快不快。
