为什么使用phpMyAdmin导出大表会导致服务器CPU飙升？-phpMyAdmin-PHP中文网

phpmyadmin导出大表时cpu飙升的真正源头是php用户态处理：逐行html转义、类型推断、链接生成等操作耗尽cpu；$cfg['maxrows']对导出无效，因导出直接执行无limit查询；应改用mysqldump、select into outfile或分批导出。

为什么使用phpmyadmin导出大表会导致服务器cpu飙升？

phpMyAdmin导出大表时CPU飙升的真正源头

不是MySQL在扫描，是phpMyAdmin把整张表结果集读进PHP内存后，逐行做HTML转义、类型推断、字段链接生成（比如自动给邮箱加mailto:）、字符截断、分页计算——这些操作全在PHP用户态完成。百万行 × 每行10字段，光是htmlspecialchars()调用就能吃满一个CPU核。

为什么`$cfg['MaxRows']`对导出无效

$cfg['MaxRows']只控制“查询结果页面显示行数”，不影响导出逻辑。导出时phpMyAdmin会无视该设置，直接执行无LIMIT的SELECT，再把全部结果拼成单个字符串输出。哪怕你界面上只看了前50行，点“导出”仍会拉全表。

导出触发的是PMA\libraries\export\ExportSql::exportData()或ExportCsv::exportData()，它们不检查$cfg['MaxRows']
真正起作用的是$cfg['SQLQuery']['AsIs'] = true;，防止它自动包裹SELECT * FROM (…)导致索引失效
导出CSV时若含TEXT字段，str_replace()和fputcsv()模拟还会额外触发大量字符串复制

导出卡住时`top`里看到的不是`mysqld`而是`php-fpm`

执行top -u www-data（或对应PHP用户），如果看到php-fpm进程CPU持续90%+，而mysqld只有20%以下，就确认是phpMyAdmin后处理瓶颈。此时SHOW PROCESSLIST里MySQL线程状态可能是end或query end，说明数据早已传完，PHP还在自己那儿忙活。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

关键指标：vmstat 1中cs（context switch）飙升 > 15k/s → PHP GC在疯狂清理ZVAL引用
strace -p $(pgrep php-fpm) -e trace=write,sendto能看到大量小块write(1, ...)，证明它没走流式输出，而是在攒大字符串
禁用$cfg['ServerDefault']并清空多余服务器配置，能减少mysqli对象残留对GC的压力

别在界面上导出百万行：三个立刻生效的替代方案

phpMyAdmin导出本质是反模式——它把数据库当API、把浏览器当终端。真要导数据，绕过它。

命令行mysqldump：用mysqldump --no-create-info --skip-extended-insert -u user -p db table > data.csv，全程MySQL服务端流式处理，PHP零参与
SQL级SELECT INTO OUTFILE：执行SELECT * FROM table INTO OUTFILE '/tmp/data.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';，需MySQL有FILE权限且路径在服务端
分批导出+本地合并：在phpMyAdmin里手动加LIMIT 10000 OFFSET 0，导10次，再用tail -n +2 *.csv | cat header.csv - > full.csv合并，避免单次内存爆炸

最常被忽略的一点：导出前先确认SELECT本身是否真的需要全表。很多所谓“大表导出”，其实只要导最近3个月数据——加WHERE created_at > '2026-06-01'，可能从千万行降到五万行，phpMyAdmin都能扛住。