直接调高memory_limit治标不治本，因phpMyAdmin导出需全量加载结果集至内存；真正应绕过PHP内存加载，改用mysqldump流式导出、分页查询或禁用驱动缓冲等方案。
直接调高 memory_limit 能临时缓解，但多数情况下治标不治本——phpmyadmin 导出本质是把整张表或全部查询结果加载进 php 内存再拼字符串，数据一过几万行、含 blob 或长文本，就必然崩。真正该做的是绕过 php 内存加载环节。
为什么改了 memory_limit 还报 Allowed memory size exhausted
因为有三道独立的内存闸门，漏掉任意一个都会失败：
-
php.ini或 PHP-FPM pool 配置里的memory_limit（Web SAPI 下生效） - phpMyAdmin 自身在
libraries/classes/Util.php或vendor_config.php中调用的ini_set('memory_limit', ...)（会覆盖 php.ini 设置） - config.inc.php 里的
$cfg['MemoryLimit']（单位字节，设为0表示不限，非零值会强制截断）
查当前真实生效值：在 phpMyAdmin 根目录放 info.php，内容为 <?php phpinfo(); ?>，搜 Loaded Configuration File 和 memory_limit；再打开 phpMyAdmin 的“服务器信息”页，看底部“PHP 设置”区域是否一致。
导出卡住或报错时优先换流式方案
phpMyAdmin 的“全选导出”对大结果集就是反模式。与其硬扛内存，不如让数据流着走：
- 启用
mysqldump后端：确认config.inc.php中有$cfg['Export']['use_mysqldump'] = true;，且$cfg['ExecDir']指向mysqldump可执行路径（如/usr/bin） - 命令行直出更可靠：
mysqldump -u root -p --single-transaction --where="id BETWEEN 1 AND 50000" database_name table_name > part1.sql - 若必须用界面，勾掉
Save as file，选Display output as text，复制粘贴到本地保存——避开浏览器上传/下载链路的缓冲和超时
分页导出比调内存更可控
手动拆分不是妥协，而是明确控制内存驻留规模：
立即学习“PHP免费学习笔记（深入）”；
- 在 SQL 查询页写带
LIMIT的语句，例如：SELECT * FROM logs WHERE created_at > '2026-05-01' LIMIT 10000 OFFSET 0 - 导出前先估算量级：
SELECT COUNT(*) FROM ...，超 5 万行就别“全选”，按主键或时间字段分段 - 禁用 phpMyAdmin 默认的“显示全部”行为：在
config.inc.php加$cfg['MaxRows'] = 5000;，让浏览页默认只拉 5000 行，降低误操作风险
容易被忽略的底层瓶颈：MySQL 结果集缓存
哪怕你只 fetch 一行，PDO/MySQLi 默认也会把整张结果集从 MySQL 拉进 PHP 内存——这才是真正的内存黑洞：
- PDO 必须关缓冲：
$pdo->setAttribute(PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, false);，再用query()+fetch() - MySQLi 必须用
mysqli_use_result()（非默认的mysqli_store_result()） - 导出脚本里别用
fetchAll()，改用循环 +fputcsv($fp, $row)+unset($row)，每行处理完立刻释放
真正耗内存的往往不是导出逻辑本身，而是数据库驱动没关缓冲、数组没 unset、CSV 字符串拼接成大块——这些细节比调 memory_limit 关键得多。
