
本文详解 laravel 使用工厂进行百万级数据填充时出现内存溢出的根本原因(n+1 查询、对象未释放、查询累积),并提供基于分批处理、禁用模型事件、手动垃圾回收等实战优化策略。
本文详解 laravel 使用工厂进行百万级数据填充时出现内存溢出的根本原因(n+1 查询、对象未释放、查询累积),并提供基于分批处理、禁用模型事件、手动垃圾回收等实战优化策略。
在 Laravel 中执行大规模数据填充(如 100 万条记录)时,看似简洁的工厂调用代码极易引发严重的内存泄漏问题——例如你遇到的 Allowed memory size of 134217728 bytes exhausted 错误,往往在迭代至约 2000 次时即崩溃。根本原因并非单纯“PHP 内存不足”,而是典型的架构性资源滥用:每轮循环中创建的 Eloquent 模型实例未及时释放,关联操作触发大量重复查询(即“N+1 问题”),且数据库连接层持续缓存查询上下文,最终导致内存呈线性增长直至耗尽。
? 问题定位:为什么 $terms 覆盖仍会内存泄漏?
尽管你在每次迭代中重新赋值 $terms,但 Eloquent 的以下行为仍会持续占用内存:
- Term::factory(10)->create() 创建的 10 个模型实例及其关联的 Question 实例全部保留在 PHP 的对象图中;
- saveMany() 触发 10 次独立 INSERT 查询,并为每个 Question 实例建立完整的模型生命周期(事件监听、属性变更跟踪、关系缓存);
- Laravel 的查询构建器和连接器(如 Connection.php)内部维护 SQL 绑定、PDO 语句句柄及日志缓冲区,高频调用下无法及时 GC。
✅ 推荐优化方案(按优先级排序)
1. 改用原生批量插入(零模型开销)
跳过 Eloquent,直接使用 DB::table()->insert() 批量写入原始数组,彻底规避模型实例化:
use Illuminate\Support\Facades\DB;
$count = 10_000;
$batchSize = 500; // 每批插入 500 条 term + 关联 questions
for ($i = 0; $i insertGetId(['name' => 'Term_' . uniqid()], 'id');
$termsData[] = $termId;
// 为该 term 预生成 10 个 question 数据(含外键)
for ($q = 0; $q $termId,
'title' => 'Question_' . uniqid(),
'created_at' => now(),
'updated_at' => now(),
];
}
}
// 批量插入所有 questions(单次查询)
DB::table('questions')->insert($questionsData);
// 强制释放内存(可选但推荐)
unset($termsData, $questionsData);
gc_collect_cycles();
}
2. 若必须使用 Eloquent:禁用事件 + 分块 + 显式清理
use Illuminate\Database\Eloquent\Factories\Factory;
// 关键:全局禁用模型事件,避免监听器驻留内存
Factory::disableModelEvents();
$count = 10_000;
$batchSize = 100;
for ($i = 0; $i create();
$questionsData = [];
foreach ($terms as $term) {
// 使用 make() + 手动设置外键,避免 saveMany() 的模型关联开销
$questions = Question::factory(10)->make(['term_id' => $term->id]);
foreach ($questions as $q) {
$questionsData[] = $q->getAttributes(); // 提取纯数组
}
}
// 批量插入 questions
DB::table('questions')->insert($questionsData);
// 主动释放模型引用(关键!)
$terms->each->unsetRelation('questions');
unset($terms, $questionsData);
gc_collect_cycles(); // 强制垃圾回收
}
Factory::enableModelEvents(); // 恢复事件(如需)
3. 其他必备优化项
-
关闭查询日志(开发环境默认开启,严重拖慢大批量操作):
DB::disableQueryLog(); // 在 seeder 开头调用
-
调整 MySQL 批处理参数(服务端配合):
在 my.cnf 中增大 max_allowed_packet 和 innodb_buffer_pool_size。 - 使用 --no-interaction 和 --force 运行:避免 Artisan 命令行组件额外开销。
⚠️ 注意事项
- 不要依赖 ini_set('memory_limit', ...) 临时扩容——这只是掩盖问题,无法解决 OOM 根本原因;
- withProgressBar() 本身不造成内存泄漏,但其闭包内逻辑若未优化,会放大问题;
- factory()->create() 应仅用于测试或小规模数据;生产级大批量填充必须转向 insert() 或 upsert();
- 使用 gc_collect_cycles() 并非万能,但对循环中高频创建/销毁对象的场景有显著效果。
通过上述组合策略,原本 2000 次迭代即崩溃的填充任务,可稳定完成 100 万级数据写入,内存占用维持在 20–40 MB 区间,执行效率提升 5–10 倍。核心原则始终是:让数据库做它最擅长的事(批量写入),让 PHP 少做它最不擅长的事(管理百万级对象生命周期)。










