phpMyAdmin导入大SQL时PHP进程被kill，基本是OOM Killer所致；必须同步调整upload_max_filesize、post_max_size、max_execution_time和memory_limit四参数并重启Web服务，但根本解法是绕过Web层，改用mysql命令行导入。
phpMyAdmin导入大SQL时PHP进程被kill，基本就是OOM Killer干的
不是配置没生效，也不是phpmyadmin坏了——linux内核发现内存吃紧，直接按oom_score挑最占内存的进程杀掉。而phpmyadmin导入时会把整个sql文件读进php内存再解析执行，一旦文件超100mb或含百万级insert，php子进程rss飙升，立刻成为oom killer头号目标。
验证方式很简单：dmesg -T | grep -i "killed process"。如果输出里出现Killed process 12345 (php-cgi)或类似记录，就坐实了。
别只盯着php.ini调memory_limit——那是软限制，OOM Killer根本不认。
必须同步改全这四个PHP参数，缺一不可
只改upload_max_filesize是最常见翻车点。POST上传、脚本执行、内存三道关卡有依赖关系，漏一个都会在不同阶段失败：
-
upload_max_filesize = 512M（上传文件上限） -
post_max_size = 512M（必须 ≥upload_max_filesize，否则表单提交在PHP入口就被截断） -
max_execution_time = 600（默认30秒，大SQL解析+执行必超时） -
memory_limit = 512M（PHP进程内存上限，要明显大于SQL文件大小，否则读取阶段就OOM）
改完后必须重启Apache（不是只刷新页面），并在phpinfo()里搜索确认值已更新。Windows下注意文件属性是否被设为“只读”。
立即学习“PHP免费学习笔记（深入）”；
为什么改完参数还是500或白屏？phpMyAdmin自身架构是瓶颈
即使PHP参数全放开，phpMyAdmin仍会把整个SQL加载进内存、切片执行。它不是为大数据设计的工具，本质是Web层封装，存在硬性天花板：
- 导入页底部显示的
upload_max_filesize值只是参考，实际限制还受Web服务器（如Apache的LimitRequestBody或Nginx的client_max_body_size）影响 - 勾选了
gzipped压缩格式，PHP还要额外解压——又一轮内存和时间消耗 - 含大量
INSERT ... VALUES (...),(...),(...)的单语句，PHP解析器容易卡死或栈溢出
此时继续调参意义不大。真正可靠的路径是绕过整个Web层。
用mysql命令行导入，彻底避开PHP和OOM Killer
这是最稳定、最快、也最不容易出错的方式，完全不经过PHP上传、解析、执行流程：
- 确保MySQL服务正在运行（phpEnv/XAMPP控制面板显示Running）
- 打开CMD，cd到MySQL的
bin目录（如C:\phpenv\mysql\bin） - 执行：
mysql -u root -p --default-character-set=utf8mb4 database_name（输密码后回车） - 进入MySQL后，用
source C:/path/to/your/file.sql导入（路径用正斜杠或双反斜杠，避免转义问题）
注意：如果SQL文件本身含CREATE DATABASE或USE语句，需提前创建好数据库，或先用mysql -e "CREATE DATABASE ..."建库。字符集不匹配会导致中文乱码，--default-character-set=utf8mb4不能省。
