Laravel查询缓存技巧与配置方法

Laravel的数据库查询缓存并非开箱即用的自动优化机制，而是必须通过显式调用`remember()`方法手动启用，它只缓存`get()`、`first()`等终端操作的实际结果（如模型集合或数组），而非SQL模板；缓存键由真实执行的SQL语句与参数值共同生成，因此不同参数、关联加载或动态表达式都会产生独立缓存项；更关键的是，缓存不会随模型数据更新自动失效，需在模型事件中主动清除，否则极易导致陈旧数据问题；同时应避免与`Cache::remember()`嵌套使用，并警惕在用户专属查询、含随机/时间函数的SQL或超大结果集等低效场景下滥用——真正值得缓存的是那些读多写少、SQL稳定、命中率高且体积适中的公共数据，如配置项、分类列表或热门排行。

直接说结论：Laravel 的数据库查询缓存不是开个开关就自动生效的，它依赖 remember() 显式调用，且只缓存终端结果，不缓存查询过程；缓存键由实际 SQL + 参数值生成，不是模板，也不随模型变更自动失效。

为什么 remember() 缓存的是结果，不是 SQL 语句？

很多人误以为 remember() 是给 where() 或 orderBy() 这些构建器“记住了 SQL 模板”，其实不是。它只在调用 get()、first()、count() 等终端方法时，把最终返回的数组或模型对象序列化后存进缓存。

• Post::where('status', $status)->remember(3600)->get() —— 缓存的是 get() 返回的那批 Post 实例（含关联时也一并序列化）
• toSql() 看到的只是占位符（如 where status = ?），但 Laravel 生成缓存键时已把 $status 的真实值代入，所以 $status = 'draft' 和 $status = 'published' 是两个完全不同的缓存键
• 中间链式调用（如 with('author')）会影响结果结构，也会改变缓存键——因为 SQL 和绑定参数都变了

缓存失效必须手动处理，Laravel 不监听模型变更

这是线上最常踩的坑：数据明明更新了，页面还是旧内容。因为 remember() 不和 Eloquent 事件联动，save()、delete() 后缓存还稳稳躺在 Redis 里。

• 推荐在模型的 saving / deleting 事件中主动清除对应缓存，例如：Cache::forget('posts_active_list')
• 如果用了自定义键名（强烈建议这么做），就别依赖默认键——它由 SQL 哈希生成，调试时根本看不出来源
• 避免用 rememberForever()，一旦写错逻辑，只能靠 redis-cli flushdb 或人工删键，生产环境极难补救

别和 Cache::remember() 套娃，底层是同一个东西

有人会这样写：Cache::remember('key', 3600, fn() => Post::where(...)->get())，再在模型里又加一层 ->remember(3600)。这不仅多余，还可能出问题。

• remember() 查询构建器方法，底层就是调用 Cache::remember()，重复包一层等于两次哈希、两套过期逻辑
• 闭包执行时机不同可能导致缓存值为空数组（比如闭包里抛异常但没被捕获）
• 真要按用户角色、状态等维度分键，应该放弃 remember() 链式调用，改用 Cache::remember("posts_{$role}_{$status}", ...) 手动控制

高频低命中 or 动态 SQL 场景下，remember() 反而拖慢响应

缓存不是万能加速器。有些查询加了 remember() 后，性能更差。

• 查当前用户订单：where('user_id', auth()->id()) —— 每个用户键都不同，缓存利用率趋近于 0，纯占内存
• SQL 里带 DB::raw('NOW()') 或 RAND() —— 每次生成的 SQL 都不一样，缓存键永不复用，等于白开
• 单次查询结果超 1MB（比如导出全量日志）—— 序列化/反序列化 + 网络传输开销可能超过重查数据库

真正该缓存的，是那些读多写少、SQL 稳定、命中率高、体积适中的公共数据，比如站点配置、分类列表、热门文章排行。这些地方加 remember() 才有实际收益。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~