phpMyAdmin 导入大 SQL 文件失败的根本原因是三阶段底层限制：上传阶段受 upload_max_filesize 和 post_max_size 拦截，解析阶段因 PMA_SQP::parse() 全量加载导致内存爆炸，执行阶段无流式处理；唯一可靠方案是跳过 phpMyAdmin，改用 mysql 命令行导入。
直接改 php.ini 参数不能彻底解决，因为 phpmyadmin 导入大 sql 文件时的内存爆掉，根本不在 php 内存限制这层——它卡在上传阶段、解析阶段、执行阶段三道关，每道关都绕不开底层机制限制。
为什么 ini_set('memory_limit', '512M') 在 config.inc.php 里写没用？
上传逻辑发生在 phpMyAdmin 加载配置之前，ini_set() 根本没机会执行。更关键的是，PHP 的 upload_max_filesize 和 post_max_size 会在文件进 PHP 进程前就拦截请求，报错是 “File exceeds the maximum allowed size”，连内存限制那关都到不了。
- 必须改
php.ini，不是config.inc.php -
upload_max_filesize和post_max_size要设为相同值（比如512M），且post_max_size ≥ upload_max_filesize - 改完必须重启 Apache 或 PHP-FPM，否则不生效
即使文件传上去了，PMA_SQP::parse() 仍会崩
phpMyAdmin 不流式解析 SQL，而是把整个字符串一次性读进内存，调用 PMA_SQP::parse() 做 tokenize。一个含 50 万行 INSERT 的文件，哪怕只有 20MB，tokenize 后内存占用轻松破 1G。
- 这不是配置能救的，是架构决定的：它没有 chunking、没有 streaming parser
-
$cfg['MemoryLimit']在 config.inc.php 里设了也无效——该参数只影响导出预览等少数场景，不控制 SQL 解析 - 别信“加
set_time_limit(0)就能扛住”，超时只是表象，内存耗尽才是真因
真正有效的导入方式：跳过 phpMyAdmin，用 mysql 命令行
MySQL 客户端自带缓冲和流式执行能力，不经过 PHP 内存加载，也不受 upload_max_filesize 约束，是唯一稳定路径。
- 确认 MySQL 可执行：
which mysql和mysql --version能返回结果 - 执行：
mysql -u root -p --default-character-set=utf8mb4 database_name < /path/to/large.sql（注意字符集，防中文乱码） - 若 SQL 含
CREATE DATABASE或权限语句，加--force参数避免中途退出：mysql -u root -p --force --default-character-set=utf8mb4 < large.sql - 如果文件里有
USE database_name，命令行可不指定库名，但要确保当前用户有对应权限
误配 $cfg['UploadDir'] 是常见陷阱
很多人以为设了 $cfg['UploadDir'] = '/var/lib/phpmyadmin/upload'; 就能绕过上传限制，其实这只是开放一个下拉菜单，列出该目录下的 .sql 文件供点击执行——文件仍被全量读入 PHP 内存，再经 PMA_SQP::parse() 解析，内存压力一点没少。
立即学习“PHP免费学习笔记（深入）”；
- 该目录权限必须是 webserver 用户（如
www-data）可读，否则列表为空 - 它唯一价值是规避 HTTP 上传限制，但没解决核心解析内存问题
- 若真要用，只放已拆分好的小文件（≤2MB），并配合执行前手动设：
SET SESSION max_allowed_packet = 268435456;
最易被忽略的一点：错误行号不准 + 静默中断。phpMyAdmin 报的 #1064 行号常滞后 3–5 行，且内存溢出时往往不报任何位置信息。用命令行导入，错误输出带真实行号和上下文，这才是定位语法问题的可靠方式。
