phpmyadmin 不能直接修改 laravel 缓存表的过期时间——_cache 表中 expiration 字段为只写时间戳，laravel 读取时仅校验是否过期且不支持手动“复活”，真正控制缓存时效的是代码中 cache::put() 的参数或 config/cache.php 中的 ttl 配置。
phpmyadmin 不能直接修改 laravel 缓存表的过期时间——_cache 表里的 expiration 字段是时间戳，改它没用，laravel 读取时只校验当前时间是否超过该值，但缓存逻辑本身不依赖你手动更新这个字段。
为什么改 _cache 表的 expiration 字段无效
Laravel 的 database 缓存驱动在写入时自动生成 expiration（基于 Carbon::now()->addSeconds($seconds)），读取时调用 Cache::get() 会自动跳过已过期记录（SQL WHERE 条件包含 expiration > UNIX_TIMESTAMP()）。你手动把某条记录的 expiration 改大，下一次 Cache::put('key', $val, 300) 还是会覆盖它；而如果该 key 已被自动清理（比如通过 php artisan cache:prune 或定时任务），这条记录甚至可能早就不存在了。
常见错误现象：UPDATE cache SET expiration = UNIX_TIMESTAMP() + 3600 WHERE key = 'foo'; 执行后 Cache::has('foo') 仍返回 false —— 因为 Laravel 永远不会“复活”一条过期记录，它只写新、不修旧。
真正有效的调整方式：改配置而非改表
缓存项的过期时长由代码中 Cache::put()、Cache::remember() 等调用时传入的秒数决定，或由默认配置兜底。数据库表只是存储载体，不是控制中心。
- 全局默认 TTL（仅对未显式指定过期时间的
put()生效）：修改config/cache.php中'stores' => ['database' => [... 'ttl' => 3600]] - 单次写入控制：用
Cache::put('key', 'val', 7200)显式传入秒数，比配置更优先 - 使用
Carbon实例：支持Cache::put('key', 'val', now()->addMinutes(10))，Laravel 内部会转成时间戳 - 注意迁移兼容性：Laravel 9+ 的
cache表结构要求expiration是INT UNSIGNED，别误设成DATETIME
哪些场景下你会想“改表”？其实该换方案
如果你正在 phpMyAdmin 里翻 _cache 表，试图延长某个配置项、Token 或临时数据的生命周期，大概率说明设计上出了偏差：
- 长期有效数据不该走
cache表——改用settings或configs自定义表，配 CRUD 接口 - 需要手动干预过期行为（如运营后台临时延长活动缓存）：加个开关字段到业务表，让代码逻辑绕过缓存读取
- 调试时想看某条缓存内容：用
Cache::get('key')查，别依赖 phpMyAdmin 刷新——因为Cache::get()会自动触发过期清理，表里残留的过期记录不代表还能取到 - 发现缓存大量堆积：检查是否漏了
Cache::forget()，或用了永不过期的Cache::forever()，这时该删数据而不是调时间
真正要动 _cache 表的时候，基本只有两个动作：清空（TRUNCATE cache）或查死链（SELECT * FROM cache WHERE expiration ）。其他所有“调过期时间”的想法，都应该回到 PHP 代码层解决——表只是结果，不是开关。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
