phpEnv如何快速导入几百MB的SQL脚本？

phpEnv 里直接用 phpMyAdmin 导入大 SQL 文件会卡死

phpEnv 自带的 phpMyAdmin 默认限制上传文件大小（通常 2M），且脚本执行时间短、内存上限低。几百 MB 的 SQL 文件一上传就报 413 Request Entity Too Large 或导入中途 502 Bad Gateway，根本走不到执行阶段。

这不是 phpMyAdmin 坏了，是它压根没设计用来干这事——它面向的是开发调试场景，不是数据迁移。

• upload_max_filesize 和 post_max_size 默认都是 2M 或 8M，必须改
• max_execution_time 默认 30 秒，大文件解析+执行远超这个值
• 即使调高参数，phpMyAdmin 仍可能因内存溢出（memory_limit）崩溃，尤其含大量 INSERT 的文件

最稳的方式：跳过浏览器，用命令行 mysql 客户端直连导入

phpEnv 启动 MySQL 后，自带完整命令行工具，路径通常在 phpEnv\MySQL\bin\mysql.exe（Windows）或 phpEnv/MySQL/bin/mysql（Linux/macOS）。你不需要配环境变量，直接进目录运行就行。

操作步骤很直接：

• 把 SQL 文件放到一个**无中文、无空格、路径尽量短**的位置，比如 C:\data\big.sql
• 打开终端（CMD 或 PowerShell），cd 进入 phpEnv\MySQL\bin 目录
• 执行：

  mysql -u root -p your_database_name < C:\data\big.sql

• 输入密码（默认通常是 root，若改过请填实际密码）

注意：your_database_name 必须**提前建好**（可用 phpMyAdmin 点几下创建），且编码设为 utf8mb4；如果 SQL 文件里没带 CREATE DATABASE，也不能用 mysql -e "source ..." 替代——source 只在交互式 MySQL shell 里有效，不支持重定向导入。

如果必须用 phpMyAdmin，只改配置还不够，还得切分文件

硬调 upload_max_filesize = 512M 看似解法，但 phpEnv 的 Apache + PHP 组合在 Windows 下对超大 POST 请求稳定性差，经常卡在 99% 或静默失败。真要走这条路，得配合文件拆分：

• 用 split（Linux/macOS）或 gsplit（Windows 上装 GNU Coreutils）把大 SQL 按行数切块，例如每 1000 行一个文件：

  split -l 1000 big.sql chunk_

• 确保每个分块以完整语句结尾（避免 INSERT 被截断），可用文本编辑器检查末尾是否含 ;
• 逐个上传导入，顺序不能乱（尤其含 DROP TABLE 或外键依赖时）

别信“自动识别语句边界”的在线分割工具——它们常把注释、多行字符串当语句切开，导致语法错误。

临时启用 BigDump 是折中方案，但要注意权限和路径

BigDump 是个纯 PHP 脚本，适合没 SSH 权限又不想动服务器配置的场景。在 phpEnv 中部署它需注意三点：

• 把 bigdump.php 放到 phpEnv 的网站根目录下（如 phpEnv\www\），确保能通过 http://localhost/bigdump.php 访问
• SQL 文件不能放 web 目录下（有被下载风险），应放在 phpEnv\www\uploads\ 这类非公开目录，并在 bigdump.php 里修改 $filename 路径指向它
• 导入前务必在脚本里设好 $db_server（填 127.0.0.1，别用 localhost）、$db_name、$db_username、$db_password，否则连不上本地 MySQL

BigDump 不会一次性读全文件，而是按批次执行，所以对内存友好。但它无法处理含存储过程、事件或复杂事务的 SQL —— 遇到 DELIMITER 就会报错，这类文件只能走命令行。

真正耗时的从来不是“怎么导入”，而是确认 SQL 文件本身是否干净：有没有 CREATE DATABASE 冲突、字符集声明是否统一、是否混用了引擎类型。几百 MB 的文件一旦出错，回溯成本极高，建议先用 head -n 100 big.sql 扫一眼开头结构，再动手。