使用 db::table()->insert() 批量插入可提速 5–10 倍，需控制每批 ≤1000 行、关闭事件与外键检查、禁用事务日志、预生成 faker 数据、避免 factory()->create() 隐式开销。
用 DB::table()->insert() 替代模型 save() 或 create()
模型逐条写入在生成数万条数据时会明显变慢，因为每条记录都触发了 Eloquent 的事件、类型转换、验证（即使没显式写）、属性赋值等开销。直接走查询构造器批量插入，能跳过这些，速度通常快 5–10 倍。
实操建议：
- 在 Seeder 中用
DB::table('users')->insert($rows)，其中$rows是二维数组，每项是字段名 => 值的关联数组 - 单次
insert()最好控制在 1000 行以内（MySQL 默认max_allowed_packet可能限制大批次） - 避免在循环里反复调用
insert()，应攒够一批再插，比如每 500 条 flush 一次 - 记得提前关闭模型事件：在 Seeder 开头加
Model::unsetEventDispatcher()，否则即使不用模型，某些全局监听仍可能被触发
禁用外键检查和事务自动提交
默认 Laravel Seeder 在事务中运行，对数万条数据来说，事务日志膨胀、锁持有时间长、内存占用高，容易超时或 OOM。同时外键约束也会拖慢插入速度。
实操建议：
- 在 Seeder 开头执行
DB::statement('SET FOREIGN_KEY_CHECKS = 0')，结尾再设回1 - 显式关闭事务：在
run()方法开头加DB::disableQueryLog()（防内存爆）和DB::beginTransaction()不要加；如果真要用事务，务必分段commit()，而不是包整个 Seeder - MySQL 下可临时调大
innodb_log_file_size和bulk_insert_buffer_size，但生产环境慎改，仅限本地/CI 环境
用 Faker 配合数组预生成，别在循环里实时调用
Faker 实例每次生成字符串、日期等都有一定开销，嵌套在万级循环里会累积成可观延迟，尤其用了 unique() 或复杂 provider 时更明显。
实操建议：
- 先用
$faker->name()等生成一个含 1000 个名字的数组，再按需 slice 分配，而不是每次循环都调一次 - 避免在
insert()数据前用$faker->unique()->numberBetween()——它内部维护哈希表，大数据量下内存和查找成本陡增；改用数据库层去重（如先插再DELETE重复）或应用层布隆过滤 - 对固定枚举字段（如
status），直接用['active', 'inactive'][array_rand(['active', 'inactive'])]，比$faker->randomElement()轻量得多
小心 factory()->count()->create() 的隐式开销
Laravel 8+ 的工厂默认走 Eloquent create()，哪怕你只想要原始数据，它仍会实例化模型、调用 make()、处理 for() 关系、触发 creating 事件——这对批量场景完全是冗余负担。
实操建议：
- 不要用
UserFactory::new()->count(10000)->create()，改用UserFactory::new()->count(10000)->make()->toArray()得到纯数组，再喂给DB::table()->insert() - 如果工厂里定义了
for()关系，make()仍会 eager 加载关联模型，导致 N+1；此时应拆解：先批量生成主表数据，再单独批量生成从表，并用外键数组对齐 - 工厂的
definition()中避免调用 DB 查询（如User::inRandomOrder()->first()），这类操作在万次循环里会直接拖垮 Seeder
真正卡住的往往不是“怎么生成”，而是“谁在悄悄拦路”——比如某个被遗忘的 Observer、一条没关的 Query Log、或是 MySQL 的 autocommit=1 在大批量时反复刷盘。跑之前先 php artisan tinker 里试 100 条，看 DB::enableQueryLog() 输出里有没有意外语句，比硬扛超时更省时间。
