内存控制与事务提交必须协同优化：分批写入（200–800条/批，依字段复杂度调整），每批后gc_collect_cycles()；事务按业务一致性分级处理，CLI需调优运行环境并禁用非DB操作。
大批量数据写入时，内存控制和事务提交不是两个独立问题，而是紧密咬合的执行链。不控内存，事务会因超限中断；不设合理事务边界，内存再小也扛不住锁等待和日志堆积。
分批切片是内存控制的第一道防线
别指望一次 insertAll() 吃下 10 万条。实测 Web 环境下，单次 200–400 条最稳；CLI 脚本可放宽到 500–800 条，但必须配合 array_chunk 主动拆分：
- 字段少（≤5 个普通类型）、无大文本：用 array_chunk($data, 400)
- 含 JSON、TEXT 或 Base64 字段：压到 200 条/批，避免触发 max_allowed_packet
- 每批处理完立即调用 gc_collect_cycles()，尤其循环多批次时，能显著抑制内存持续爬升
事务粒度要匹配业务一致性要求
不是所有批量都值得包进一个事务。事务越长，锁表时间越久，超时与死锁风险越高：
- 纯数据导入（如 Excel 补全、日志归档）：无需手动事务 —— Db::insertAll() 默认走单条多值 SQL，MySQL 自动隐式提交，更快更轻
- 跨表强依赖（如“写订单 + 扣库存”）：必须用 Db::transaction() 闭包包裹整组操作，失败自动回滚
- 单表百万级更新：按主键或时间范围分段，每 500–1000 行一个事务，既保原子性，又防锁等待
CLI 脚本需额外加固运行环境
Web 请求有超时和内存限制，CLI 脚本虽自由，但默认配置极易翻车：
立即学习“PHP免费学习笔记（深入）”；
- 开头加 set_time_limit(0) 和 ini_set('memory_limit', '1G')（根据数据量调整）
- 禁用调试与日志：App::debug(false) + Log::close()，IO 开销可降 30%+
- 避免在事务内做非 DB 操作（发邮件、调 API、写文件），否则 rollback 无法覆盖，且拉长锁持有时间
性能临界点要靠实测校准
所谓“500 条安全”只是基准线，真实瓶颈取决于你的字段结构和 MySQL 配置：
- 查当前 max_allowed_packet：SHOW VARIABLES LIKE 'max_allowed_packet';（单位字节）
- 估算单行平均体积：字符串长度 + 字段数 × 10 字节（粗略），再 × 批次数量，别超 80% 上限
- 若报错 Packets larger than max_allowed_packet，立刻减半批次量并检查是否有意外的大字段混入
