唯一可靠方案是禁用phpMyAdmin全表导出，改用服务端mysqldump脚本+权限隔离；因其本质是PHP前端代理，整表SELECT加载内存致CPU/内存耗尽、MySQL锁死，调大PHP限制仅延迟崩溃。
直接禁用 phpmyadmin 的全表导出能力，改用服务端可控的 mysqldump 脚本 + 权限隔离，是唯一能真正防住 cpu 爆满、内存耗尽、mysql 锁死的方案。调大 memory_limit 或 max_execution_time 只会让崩溃更晚、更剧烈。
为什么 phpMyAdmin 导出会拖垮服务器
它不是“导出工具”，而是“前端代理”：浏览器点一下「导出」，phpMyAdmin 就用 PHP 进程把整张表 SELECT 出来，边读边拼 SQL 字符串，全部塞进内存再写文件。百万行数据 ≈ 数百 MB 内存+高 CPU 持续序列化+MySQL 全表扫描——mysqld 进程 CPU 占用飙到 100% 是常态，不是异常。
- 勾选「gzipped」会额外触发 MySQL 压缩线程，CPU 雪上加霜
-
max_execution_time对导出无效：MySQL 不按单条语句计时，而是持续拉取结果集 - PHP 层的
memory_limit炸了，表现是白屏或 502；MySQL 层的innodb_buffer_pool_size太小，表现是磁盘 I/O 爆满、响应延迟飙升
必须关闭的 phpMyAdmin 导出入口
别依赖界面按钮控制，要从配置和权限层硬拦截：
- 在
config.inc.php中设$cfg['MaxRows'] = 5000，限制「浏览」页默认加载行数，避免误点「全选」 - 禁用 root 登录：
$cfg['Servers'][$i]['AllowRoot'] = false - 撤掉导出账号的
FILE权限：REVOKE FILE ON *.* FROM 'exporter'@'localhost'（否则可绕过导出页，直接SELECT ... INTO OUTFILE） - 启用
$cfg['Servers'][$i]['DisableIS'] = true，隐藏INFORMATION_SCHEMA，让攻击者无法枚举表结构
用 mysqldump 替代 phpMyAdmin 导出的实操要点
这是唯一能脱离 PHP 内存模型、直连 MySQL 服务端执行的可靠路径：
- 脚本里必须用
--single-transaction（InnoDB）或--lock-all-tables（MyISAM），保证一致性且不锁库 - 密码绝不能写在命令行：
mysqldump -u user -p'pass' db会泄露到ps aux，改用~/.my.cnf（权限600） - 加
| gzip是为了省磁盘，但若 CPU 已紧张，就去掉压缩，用.sql明文输出 - 导出前先确认
mysqldump可执行：which mysqldump，Windows 下注意路径无空格、IIS_IUSRS 有执行权
大表导出仍卡？用 pt-archiver 分片导出
单表超百万行时，mysqldump 依然可能触发 MySQL 内部临时表或排序缓冲区溢出。这时该切到 pt-archiver：
立即学习“PHP免费学习笔记（深入）”；
- 按主键分批：
pt-archiver --source h=localhost,D=app,t=logs --where "id part1.sql -
--sleep 0.1控制每批间隔，把 CPU 峰值压到 30% 以下 - 必须确保
--where条件走索引，否则退化为全表扫描，压力更大 - 导出后手动拼接 SQL 文件，或用
mysql命令逐个导入，完全绕过 phpMyAdmin
真正危险的不是「导不出」，而是「导出时没人知道服务器正在被拖垮」。所有靠调大 PHP 限制、等 phpMyAdmin 自己扛的方案，都只是把崩溃从 2 分钟延后到 8 分钟——而那多出来的 6 分钟，足够让 MySQL 连接池打满、其他业务请求全部 hang 住。后台脚本 + 权限收口 + 分片机制，三者缺一不可。
