DB::table()->insert() 大批量插入会爆内存，因其将全部数据一次性拼成超长SQL并加载进PHP内存，导致OOM；应改用DB::statement()手写批量INSERT配合事务和底层配置优化。
为什么 DB::table()->insert() 大批量插入会爆内存
因为 laravel 默认把所有数据一次性构造成 sql 语句，再交给 pdo 执行。哪怕你传入 10 万条记录，insert() 也会先在 php 内存里拼出一条超长的 insert into ... values (...), (...), (...)，中间每条记录还要做参数绑定、类型转换、数组遍历——没等执行 sql，php 进程已经 oom 了。
常见错误现象：Fatal error: Allowed memory size of XXX bytes exhausted，或者进程被系统 kill（Killed 无报错）。
- 别用
collect($data)->chunk(1000)->each(fn($chunk) => DB::table()->insert($chunk))—— chunk 只是切分数组，insert()内部仍会把每个 chunk 全部加载进内存拼 SQL - 确认你的
php.ini中memory_limit不是 -1（无限制），生产环境建议设为512M或更低，靠调大内存掩盖问题是危险的 - 如果数据来自 CSV 或 API，避免先
file_get_contents()全读进内存；改用fopen()+fgetcsv()流式读取
用 DB::statement() 手写批量 INSERT 更稳
绕过 Eloquent 和 Query Builder 的封装，直接构造原生 SQL 并用 DB::statement() 执行，能彻底规避 ORM 层的内存开销。关键是控制单次语句长度和参数数量，避开 MySQL 的 max_allowed_packet 限制（默认 4MB）。
使用场景：导入日志、订单、用户行为等结构固定、无事件/监听/验证需求的原始数据。
- 单条
INSERT最多塞 1000 行（MySQL 官方推荐上限），行数再多容易触发 packet 超限或锁表时间过长 - 字段值必须手动转义：数字不用引号，字符串用
addslashes()或DB::connection()->getPdo()->quote()，NULL 写成NULL字面量 - 示例片段：
DB::statement("INSERT INTO users (name, email) VALUES ('Alice', 'a@example.com'), ('Bob', 'b@example.com')");
启用 DB::unprepared() 配合事务提升吞吐
DB::unprepared() 比 DB::statement() 更底层，跳过 PDO 的预处理逻辑，适合纯数据灌入。配合手动事务，能大幅减少磁盘 I/O 和日志刷盘次数。
性能影响明显：关掉自动提交后，10 万行插入从 3 分钟降到 20 秒以内（取决于磁盘和索引数量）。
- 务必在事务外检查并禁用外键约束：
DB::statement('SET FOREIGN_KEY_CHECKS = 0')，否则大批量失败时回滚代价极高 - 插入完成后记得恢复：
DB::statement('SET FOREIGN_KEY_CHECKS = 1')，否则后续写操作可能静默失败 - 不要在事务中混用 Eloquent 模型操作（如
User::create()），会触发模型事件和观察者，破坏事务原子性
导入配置里最常被忽略的三个点
很多团队只调了 Laravel 的 APP_DEBUG 或数据库连接池，却漏掉底层依赖项。这些配置不改，再好的代码逻辑也扛不住百万级导入。
- MySQL 的
innodb_buffer_pool_size至少设为物理内存的 50%～75%，否则大量随机写会频繁刷脏页，拖慢整库 - PHP-FPM 的
pm.max_children要匹配并发导入任务数，否则多个导入请求争抢 worker，互相卡死 - Laravel 的
config/database.php中，'options' => [PDO::ATTR_EMULATE_PREPARES => false]必须显式关闭，否则DB::statement()在某些驱动下仍会模拟预处理，悄悄吃内存
真正卡住的往往不是代码怎么写，而是 max_allowed_packet 和 innodb_log_file_size 这类 MySQL 底层参数没对齐数据量级。导 50 万行前，先连进 MySQL 执行 SHOW VARIABLES LIKE '%packet%'; 看一眼。
