phpMyAdmin导出超大表必致内存溢出，因其将整表数据加载至PHP内存拼SQL；行数≥50万或Data_length＞50MB即高危，应改用mysqldump加--quick、--single-transaction等参数流式导出。
phpMyAdmin 本身不提供导出文件大小的硬性限制机制，所谓“限制导出文件大小防内存溢出”是个误解——它不是靠限制大小来防溢出，而是根本无法可靠限制大表导出过程中的内存消耗。真正会内存溢出的，是导出动作本身：当表行数超过几十万，phpMyAdmin 就会把整张表数据加载进 PHP 内存再拼 SQL，memory_limit 很快耗尽，报错 Fatal error: Allowed memory size of xxx bytes exhausted。
所以，别指望在界面上调个参数就能“安全导出大表”。能做的只有两件事：避开 phpMyAdmin 导出大表，或提前识别并拦截高风险操作。
为什么 phpMyAdmin 导出大表必崩内存？
- 它用 PHP 脚本逐行 fetch 数据、组装 INSERT 语句，全程保留在内存里
- 即使你勾选了 gzip 压缩，压缩前的数据仍全在内存中
- 表有 200 万行、每行平均 1KB，光数据就占 2GB 内存——远超默认
memory_limit = 128M -
$cfg['MaxExportSize']或界面里的“最大行数”仅控制显示预览，不影响实际导出逻辑
怎么提前发现导出会失败？
执行这两条语句确认风险等级：
SELECT COUNT(*) FROM table_name;
立即学习“PHP免费学习笔记（深入）”；
SHOW TABLE STATUS LIKE 'table_name';
- 行数 ≥ 50 万 → 不建议用
phpMyAdmin导出（哪怕你调高了memory_limit） -
Data_length> 50MB → 几乎必然 OOM，尤其字段含 TEXT/BLOB - 注意：InnoDB 的
Data_length是估算值，实际导出体积可能翻倍（因 SQL 格式膨胀）
真要导出大表，必须换工具
mysqldump 是唯一靠谱选择，它由 MySQL 服务端流式读取，不依赖 PHP 内存：
-
--quick：关键！强制逐行读取，禁用客户端缓存结果集 -
--single-transaction：对 InnoDB 表做一致性快照，避免锁表 -
--skip-lock-tables：显式跳过 LOCK TABLES（和--single-transaction配合更稳） -
--compress：减少网络传输量（远程导出时有效） - 加
| gzip > table.sql.gz直接压缩输出，避免生成超大中间文件
示例命令：
mysqldump --single-transaction --skip-lock-tables --quick -u root -p database_name table_name | gzip > table_name.sql.gz
如果只能用 phpMyAdmin，怎么最小化风险？
- 只导出结构（不导数据）：
Structure only模式永远安全 - 分表导出：在“自定义”导出页，取消勾选大表，只导小表 + 结构
- 导出带
LIMIT的子集（需手写 SQL）：
然后在导出页选“从当前显示的结果导出”，但注意这不能保证一致性，且不包含建表语句SELECT * FROM huge_table LIMIT 100000;
真正的分片、断点续传、压缩、字符集控制——这些能力 phpMyAdmin 全都不具备。越想在它里面“限制大小保安全”，越容易掉进假安全感的坑里。
