web请求超时主因是php或web服务器中断脚本，而非数据库；应改用cli+队列或分片处理，避免在控制器中直接调用db::insertall($bigdata)。
Web请求超时不是数据库问题，是PHP或Web服务器中断了脚本
ThinkPHP批量插入卡在“超时”，90%的情况根本没走到数据库——PHP的 max_execution_time 或 Nginx/Apache 的 fastcgi_read_timeout / Timeout 先把进程杀掉了。错误日志里通常看不到MySQL报错，只有 PHP Fatal error: Maximum execution time of 30 seconds exceeded 或 Nginx 的 upstream timed out。
别急着调优SQL或换引擎，先确认执行环境：
- Web请求（浏览器/Postman）默认受
max_execution_time=30限制，哪怕 insertAll 只发一条SQL也会被掐断 - CLI模式下默认是
0（不限时），但很多开发者误用php public/index.php模拟Web入口，实际仍走FPM，没脱离超时控制 - 前端AJAX上传Excel后轮询接口，后端处理百万行却没设
set_time_limit(0)，10秒就断连
批量插入必须脱离Web生命周期，改用CLI + 队列或分片轮询
一次性导入10万条数据，硬扛超时既不安全也不可维护。正确路径是把耗时操作移出HTTP请求链路：
- 用户上传文件后，立即返回任务ID（如
task_20261015_xxx），前端跳转到任务状态页轮询 - 后端用
php think import:excel task_20261015_xxx命令在CLI下执行，此时可放心设set_time_limit(0)、加大内存ini_set('memory_limit', '2G') - 若无法用命令行，至少拆成固定大小的子任务：每批处理500行，用Redis记录进度，每次请求只跑一批，前端按序发起下一批请求
- 避免在控制器里直接调用
Db::insertAll($bigData)—— 这等于把整个数组加载进内存再拼SQL，OOM风险极高
insertAll 分片参数不是“可选优化”，而是超时防护刚需
Db::insertAll() 第二个参数不是用来“提速”的，是防止单次SQL过大触发MySQL或PDO层面的中断：
- MySQL 默认
max_allowed_packet=4M，5000条含文本的记录轻松突破，报错Packets larger than max_allowed_packet are not allowed - PDO 绑定参数过多（如 >65535个?占位符）会直接崩溃，跟数据量无关，只跟字段数×行数有关
- 必须用
array_chunk($data, 300)主动切片，再循环调用insertAll($chunk)，每批后加gc_collect_cycles() - 切片大小不是越大越好：300–400条是平衡点；超过500条在多数云MySQL配置下已不稳定；低于100条则网络往返开销反升
事务包裹不等于防超时，反而可能加重阻塞
很多人以为“加事务就能保证原子性”，但在超时场景下，事务是双刃剑：
- 大事务会长时间持有表锁（尤其MyISAM）或行锁（InnoDB），其他请求排队，Nginx等不及直接504
-
Db::transaction()包裹全部10万条，一旦第99999条失败，前面所有回滚操作本身又耗时数秒，进一步拖长总耗时 - 更稳妥的做法是：每批300条独立事务（或干脆不加事务），失败仅影响当前批次；用中间表记录已成功导入的主键或唯一标识，支持断点续传
- 如果业务强依赖全量成功，那就别做“大事务”，改用预校验+两阶段提交：先写入临时表，校验无冲突后再
INSERT INTO real_table SELECT ... FROM temp_table
真正卡住的从来不是 insertAll 本身，而是你把它放在了不该放的地方——HTTP请求里跑离线任务，就像让快递员开着自行车送万吨煤。分片、脱离Web、明确边界，比调任何SQL参数都关键。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
