导出大表时CPU拉满的根源是mysqld进程而非phpMyAdmin，因其执行全表扫描、序列化及压缩；应避免无条件导出、禁用压缩、改用mysqldump命令行，并调优innodb_buffer_pool_size等参数。
导出大表时 mysqld 进程 CPU 拉满，根本不是 phpMyAdmin 的锅
phpmyadmin 本身不执行导出逻辑，它只是调用 mysql 的 select ... into outfile 或拼接 mysqldump 命令再由服务器执行。真正吃 cpu 的是 mysql 服务进程（mysqld）在读取、序列化、压缩数据——尤其是导出含大量 text/blob 字段或未加条件的全表时。
实操建议：
- 确认导出是否带
WHERE条件：没加条件就导SELECT * FROM huge_table，MySQL 得扫描并缓存整张表，内存和 CPU 双爆 - 避免勾选「压缩」：phpMyAdmin 导出页勾选
gzipped或zipped，会强制 MySQL 启用压缩线程，额外占用 CPU - 改用命令行导出更可控：
mysqldump --single-transaction --skip-triggers --no-create-info db_name table_name > data.sql，比 Web 界面少一层 PHP 中转和临时文件写入开销
max_execution_time 和 wait_timeout 对导出完全无效
这两个配置管的是「查询执行时长」和「连接空闲超时」，但导出操作本质是长连接持续拉取结果集，MySQL 不按单条语句计时。即使设了 max_execution_time=1000，导出 500 万行照样跑下去，CPU 该飙还飙。
真正起作用的是：
-
innodb_buffer_pool_size：如果太小（比如默认 128M），InnoDB 频繁刷脏页+读磁盘，CPU 花在 I/O 等待上反而更高；建议设为物理内存的 50%–75% -
sort_buffer_size和read_rnd_buffer_size：导出时若涉及排序（如加了ORDER BY），过大会占内存，过小会触发磁盘临时文件，间接推高 CPU - PHP 层的
max_input_time和memory_limit：虽然不杀导出，但可能让 phpMyAdmin 在接收结果阶段崩溃，表现为「空白页」或502 Bad Gateway
用 pt-archiver 分批导出，比等 phpMyAdmin 自己扛更靠谱
当单表超过 100 万行，别指望 phpMyAdmin 一次性导完。Percona Toolkit 的 pt-archiver 能按主键分片、限速、自动 sleep，把压力摊平到数分钟甚至小时级。
立即学习“PHP免费学习笔记（深入）”；
示例（导出并保留原表）：
pt-archiver \ --source h=localhost,D=mydb,t=logs \ --where "created_at < '2024-01-01'" \ --limit 10000 \ --sleep 0.1 \ --file '/backup/logs_%Y-%m-%d.txt' \ --output-format=sql \ --no-delete
关键点：
-
--limit控制每批处理行数，--sleep控制批间停顿，两者配合可把 CPU 占用压到 30% 以下 - 必须有高效索引支撑
--where条件，否则pt-archiver会退化成全表扫描 - 导出格式用
--output-format=sql，避免生成 CSV 后再转 SQL 的二次解析开销
nginx 或 Apache 日志里搜 504 Gateway Time-out 就说明网关已放弃请求
这不是 MySQL 慢，是反向代理（如 nginx）等不及后端响应，直接断连。此时 phpMyAdmin 页面卡死、下载中断，但 mysqld 还在后台默默导着——你刷新页面重试，等于又开一个 CPU 火焰。
临时解法（仅限紧急）：
- nginx 配置里加大
proxy_read_timeout 600（单位秒），但治标不治本 - 查
SHOW PROCESSLIST，找State: Sending data且Time超 300 秒的线程，用KILL [id]主动终止，比等超时更干净 - 导出前先执行
SET SESSION sort_buffer_size = 2*1024*1024，避免会话级缓冲区反复分配释放带来的锁争用
真正要命的从来不是“能不能导”，而是“导的时候其他业务还能不能查”。资源隔离这事，得从 MySQL 用户权限、cgroups 限制、甚至物理拆库去想，光调 phpMyAdmin 设置没用。
