Laravel数据库查询缓存需显式调用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() 才有实际收益。
