phpEnv 中 phpMyAdmin 无法导入大 SQL 文件，因其默认限制上传大小（2M）、执行时间（30秒）和内存，易报413或502错误；应改用命令行 mysql 工具直连导入。
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）。你不需要配环境变量，直接进目录运行就行。
操作步骤很直接：
立即学习“PHP免费学习笔记（深入）”；
- 把 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 扫一眼开头结构，再动手。
