max_execution_time 是 PHP 导入大文件超时的主因，需结合分块导入、合理配置及 MySQL 参数协同解决。
PHP 导入超时被截断：max_execution_time 是罪魁祸首
导入大文件（比如 csv、sql 或 excel）时页面白屏、报 500、或只导入前几百行——大概率是 php 在执行中途被 max_execution_time 强制终止。这个配置默认通常只有 30 秒，而读取、解析、插入万级数据很容易超时。
- 不是所有“超时”都来自这里：Nginx 的
fastcgi_read_timeout、Apache 的Timeout、MySQL 的wait_timeout也可能协同截断，但 PHP 层最先卡住 -
set_time_limit(0)可在脚本内临时禁用限制，但仅对 CLI 模式完全可靠；Web 环境下仍可能被 SAPI 层（如 FPM）或反向代理拦截 - 修改前确认你有服务器权限：共享主机通常锁死该配置，无法通过
ini_set()或.htaccess覆盖
修改 php.ini 中的 max_execution_time
这是最彻底的改法，适用于你有后台访问权限（如 VPS、Docker、私有部署环境）。别只改数值，注意作用域和重启时机。
- 找到正在生效的
php.ini：运行php --ini（CLI）或创建phpinfo()页面查 “Loaded Configuration File” - 修改对应行：
max_execution_time = 300（单位秒，建议 300–600，避免设为 0，防止死循环拖垮服务） - 改完必须重启 PHP-FPM 或 Apache/Nginx：仅 reload 不生效，
systemctl restart php-fpm或service apache2 restart - 验证是否生效：写个
sleep(310); echo 'done';脚本测试，不能只看phpinfo()输出——它显示的是配置值，不等于运行时有效值
Web 环境下更稳妥的替代方案：分块导入 + AJAX 轮询
硬调高超时只是权宜之计，真正稳定的做法是把大任务拆成小请求，每次只处理几百条，由前端控制节奏。这样既绕开单次执行限制，又可加进度条、失败重试。
- 后端接口设计：接收
offset和limit参数，每次只读取并入库一部分数据（例如SELECT * FROM temp_import LIMIT 100 OFFSET 500） - 前端用
fetch或axios发起连续请求，上一次成功后再触发下一次，避免并发打爆数据库连接 - 关键细节：导入过程中记录当前
offset到 session 或临时表，意外中断后可续传，而不是从头再来 - 别依赖
ignore_user_abort(true)：它让脚本后台跑，但用户刷新后无法得知状态，且容易因资源未释放导致内存泄漏
导入 SQL 文件时的特殊陷阱：mysql 命令行 vs PHP mysqli::multi_query
直接用 PHP 执行超大 SQL 文件（如 100MB 的 dump.sql）极容易失败，不是因为超时，而是内存溢出或语法解析崩溃。
-
mysqli::multi_query()会一次性加载整个 SQL 字符串进内存，遇到INSERT INTO ... VALUES (...),(...),(...)长语句极易 OOM - 正确做法是用系统命令：
exec('mysql -u user -p password db_name &1', $output, $return_code)，交给 MySQL 客户端处理，PHP 只管等结果 - 注意权限与路径：确保 PHP 进程有读取
.sql文件权限，且mysql命令在$PATH中；线上环境禁用exec时，改用mysqldump分卷导出 + 小批量LOAD DATA INFILE - 别忘了设置
max_allowed_packet：MySQL 默认 4MB，导入含大字段的 SQL 会报MySQL server has gone away
超时配置只是表象，真正的难点在于任务边界怎么划、状态怎么存、中断怎么恢复——这些比改一个数字容易被忽略，也更容易在线上突然出问题。
