改了memory_limit仍报内存耗尽，因问题常不在PHP本身，而是MySQL的max_allowed_packet过小或phpMyAdmin加载全量结果集所致。
直接调大 memory_limit 通常能缓解，但大概率治标不治本——真正卡住的常是 MySQL 的 max_allowed_packet 或 PHPMyAdmin 自身对结果集的加载策略。
为什么改了 memory_limit 还报内存耗尽？
PHP 的 memory_limit 只控制 PHP 脚本能用多少内存，而 phpMyAdmin 执行 SQL 时，内存压力可能来自三个地方：
- PHP 脚本本身（比如把几万行结果全读进数组）
- MySQL 服务端在解析/传输超长语句时的缓冲区（
max_allowed_packet） - phpMyAdmin 前端尝试渲染超大结果集（比如含大 TEXT 字段的 5000 行），浏览器也会 OOM
常见现象：导入一个 20MB 的 SQL 文件，memory_limit = 512M 仍失败；或执行 SELECT * FROM huge_table 直接白屏。这不是 PHP 内存不够，而是 MySQL 拒绝接收那条超长 INSERT，或 phpMyAdmin 把整张表数据塞进 PHP 数组再转 HTML。
优先检查 MySQL 的 max_allowed_packet
这个参数决定 MySQL 单次能收/发多大的网络包，和文件大小无关，和单条语句长度强相关。默认值在 MySQL 5.7 是 4M，8.0+ 是 64M，远低于你设的 PHP 上传限制。
立即学习“PHP免费学习笔记（深入）”；
- 登录 MySQL 命令行，执行：
SHOW VARIABLES LIKE 'max_allowed_packet'; - 若返回值 ≤ 64M，且你的 SQL 中有含大 JSON、Base64 或批量 INSERT（如
INSERT INTO t VALUES (...),(...),(...)合并上千行），基本就是它 - 修改
/etc/mysql/my.cnf的[mysqld]段：max_allowed_packet = 256M，然后重启 MySQL 服务（systemctl restart mysql） - 注意：仅重载配置不生效，必须重启 mysqld 进程
限制 phpMyAdmin 结果集加载量
即使查询成功，phpMyAdmin 默认会把全部结果读进 PHP 内存再分页渲染。对大表，这比查询本身更吃内存。
- 编辑
config.inc.php，加这两行：$cfg['MaxRows'] = 500;和$cfg['LimitChars'] = 2000; -
$cfg['MaxRows']控制每页最多取多少行（不是显示多少行），设为 500 能避免一次性拉 10 万行 -
$cfg['LimitChars']限制单元格内容截断长度，防止一个 TEXT 字段占掉几百 MB 内存 - 如果只是查数据，别点「全选」或「导出全部」，先用
LIMIT 100验证语句，再分批处理
绕过 phpMyAdmin 的终极方案
生产环境处理大数据，phpMyAdmin 本就不该是主力工具。它的设计目标是管理、调试，不是吞吐。
- 导入大 SQL：用命令行
mysql -u root -p --max-allowed-packet=512M your_db ，客户端参数 <code>--max-allowed-packet可临时覆盖服务端限制 - 导出大表：用
mysqldump --single-transaction --skip-lock-tables your_db table_name > data.sql，不依赖 PHP 内存 - 查大量数据：改用
mysql -N -s -e "SELECT ... FROM ..." | head -n 1000流式输出，或写脚本用游标分页（WHERE id > ?）
真正容易被忽略的是：很多“内存耗尽”错误其实根本没走到 PHP 内存分配那步，MySQL 在连接建立后、语句执行前就因 packet 太大断开了——此时看 PHP 错误日志是空的，必须查 MySQL 的 error log 或开启 general_log 才能看到真实拒绝原因。
