本文详解 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 < $count; $i += $batchSize) {
$termsData = [];
$questionsData = [];
for ($j = 0; $j < $batchSize; $j++) {
$termId = DB::table('terms')->insertGetId(['name' => 'Term_' . uniqid()], 'id');
$termsData[] = $termId;
// 为该 term 预生成 10 个 question 数据（含外键）
for ($q = 0; $q < 10; $q++) {
$questionsData[] = [
'term_id' => $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 < $count; $i += $batchSize) {
// 创建一批 Term（不触发 saved 事件）
$terms = Term::factory($batchSize)->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 少做它最不擅长的事（管理百万级对象生命周期）。
