Laravel模型缓存设置与查询优化技巧

Laravel 的 `Cache::remember()` 是模型查询缓存的利器，但绝非“开箱即用”的自动魔法——它必须严格置于 `get()`、`first()` 等终端方法之前才能生效，依赖显式语义化缓存键（而非默认哈希）、需在模型事件中主动管理失效，且对用户私有数据、含动态函数的查询、高频更新或超大结果集等场景完全不适用；用错不仅无法提升性能，反而引发数据不一致、内存浪费和响应延迟，真正高效的缓存，始于对业务语义、命中率与生命周期的清醒判断。

Cache::remember() 是 Laravel 模型查询缓存最直接有效的手段，但它不是“开个开关就生效”的自动功能——必须显式调用、合理构造键、手动处理失效，否则缓存会变成数据不一致的根源。

为什么 remember() 必须放在 get() 或 first() 前面

remember() 是 Query Builder 的链式方法，它只在终端方法（如 get()、first()、count()）执行时才真正触发缓存逻辑。中间的 where()、with()、orderBy() 只是构建器状态，不产生缓存行为。

• 如果写成 Post::where('status', 'draft')->get()->remember(3600)，缓存根本不会生效（remember() 被调用在集合对象上，无意义）
• 正确顺序是：Post::where('status', 'draft')->remember(3600)->get()
• remember() 底层调用的就是 Cache::remember()，所以不要在外层再套一层 Cache::remember('key', 3600, fn() => ...)，纯属重复且易出错

缓存键怎么设计才不踩坑

默认键由完整 SQL + 绑定参数哈希生成，调试时完全看不出来源，线上排查极难。必须显式传入业务语义明确的键名。

• 错误示范：Post::where('category_id', $id)->remember(3600)->get() → 键是随机哈希，无法定位、无法批量清理
• 正确做法：Post::where('category_id', $id)->remember(3600, 'posts:by_category:'.$id)->get()
• 多参数场景建议用 md5(json_encode($params))，比如分页+排序：'posts:paged:'.md5(json_encode(['page' => $page, 'sort' => $sort]))
• 静态数据加版本号：'v2:config:countries'，后续结构变更只需改版本号，旧缓存自然过期

缓存失效必须自己动手，Laravel 不会监听模型变更

这是线上最常导致“页面还是旧数据”的原因：模型 save() 或 delete() 后，缓存纹丝不动。

• 在模型的 saving、deleting 事件里主动清除：Cache::forget('posts:by_category:'.$this->category_id)
• 若使用自定义键（强烈推荐），就别依赖默认键——它不可控、不可读、不可维护
• 对于 rememberForever()，更要谨慎：Cache::forget() 是唯一清除方式；Redis 中误用会导致脏数据长期存在，只能靠 redis-cli flushdb 补救，生产环境风险极高

哪些查询根本不该加 remember()

缓存不是银弹，加错了反而拖慢响应、浪费内存。

• 用户私有数据：Order::where('user_id', auth()->id())->remember(...)->get() → 每个用户一个键，命中率为零，纯占 Redis 内存
• 含数据库函数的查询：whereRaw('created_at > NOW() - INTERVAL 1 HOUR') → NOW() 每次执行值不同，缓存键永远不命中
• 高频更新数据：如实时订单状态、聊天消息列表，缓存时间稍长就会造成体验断层
• 结果体积过大：单次缓存超 1MB 的集合，序列化/反序列化开销可能超过查库本身

缓存键的业务语义、失效时机的可控性、以及是否真能复用——这三点没想清楚前，remember() 就只是给 bug 加了一层包装纸。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。