Laravel大数据处理内存不降反升的主因是Eloquent查询构建器缓存和模型引用累积；应改用cursorPaginate、禁用监听器、显式GC、优先DB::unprepared批量操作、避免Model::all()、生产禁用file缓存、清理静态属性缓存。
laravel chunk 处理大数据时内存不降反升？
不是 chunk 本身有问题，而是默认用法没释放查询上下文。Laravel 的 chunk 会缓存整个 Eloquent 查询构建器实例，每批迭代都叠加模型对象引用，尤其配合 with() 预加载时更明显。
- 改用
cursorPaginate()+ 手动游标推进，避免构建器累积状态 - 禁用模型监听器：
Event::forget('eloquent.*')（尤其在 Artisan 命令中） - 每批处理完显式调用
gc_collect_cycles()，但别太频繁（比如每 100 条一次） - 避免在
chunk回调里做DB::transaction()，事务会锁住连接并拖慢 GC
DB::statement() 和 DB::unprepared() 内存表现差很多？
DB::statement() 会走 PDO 的预处理流程，即使只是执行 UPDATE 或 DELETE，也会为每条语句创建绑定上下文；而 DB::unprepared() 直接发裸 SQL，无绑定、无结果集解析，内存开销低一个数量级。
- 批量更新/删除优先用
DB::unprepared("UPDATE ... WHERE id IN (?)")，配合array_chunk()分组 ID -
DB::statement()仅用于需要参数绑定的场景（如用户输入拼接），且务必限制单次 IN 子句长度（MySQL 默认 max_allowed_packet 影响实际能塞多少） - 执行后记得清空连接缓存：
DB::connection()->getPdo()->setAttribute(PDO::ATTR_EMULATE_PREPARES, true)可缓解部分内存滞留
队列任务里 Model::all() 导致 OOM？
Model::all() 会把全部记录一次性加载进内存，哪怕只取 id 字段——Eloquent 不会自动优化成 pluck('id')，且每个模型实例自带大量未使用的属性和关系缓存。
- 永远用
Model::query()->select('id')->chunkById(500, function ($items) { ... })替代all() - 如果只需统计或判断存在性，直接写原生 SQL：
DB::scalar("SELECT COUNT(*) FROM ...") - 避免在队列任务中使用
Cache::remember()缓存整个模型集合，改用Cache::put('key:id', $value, $ttl)单条存
config/cache.php 的 'default' => 'file' 在高并发下撑不住？
File 缓存驱动在 Laravel 中是同步阻塞的：每次 Cache::get() 都要 fopen/flock/fread，小文件尚可，但当缓存键多、值大（比如序列化了 Query Builder）时，磁盘 I/O 成瓶颈，内存反而因等待堆积而升高。
- 开发环境可保留 file，生产必须切到
redis或memcached，哪怕本地跑 Docker Redis 也比 file 强 - 检查
cache.default和cache.stores.redis.connection是否指向同一 Redis 实例，不同连接会导致连接池膨胀 - 用
php artisan cache:clear后注意观察redis-cli info memory | grep used_memory_human，确认没残留大 key
最常被忽略的是模型静态属性缓存——比如在 Trait 里定义 protected static $cache = []，它不会随请求结束销毁，长期运行的队列 worker 会越积越多。这类手动缓存必须配 TTL 或用 Cache::store('array') 隔离作用域。
