大型WordPress数据库导出失败主因是max_allowed_packet限制、内存超限及脏数据，需调服务端配置、分批导出、清理瞬态表并优选CSV或mysqldump压缩导出。
导出时提示“max_allowed_packet exceeded”或直接中断
这是大型 wordpress 数据库导出最常见的失败原因，本质是 mysql 服务端限制了单次传输的数据包大小。phpmyadmin 本身不控制这个值，它只是把请求转发给 mysql，所以必须调整服务端配置。
- 找到 MySQL 配置文件（通常是
/etc/mysql/my.cnf或/etc/my.cnf），在[mysqld]段下添加或修改：max_allowed_packet = 512M
- 同时检查 phpMyAdmin 的
config.inc.php中是否有$cfg['ExecTimeLimit'] = 0;（禁用执行超时），并确认$cfg['UploadDir']和$cfg['SaveDir']权限可写（导出大文件时 phpMyAdmin 可能临时写入） - 改完重启 MySQL：
sudo systemctl restart mysql，再重试导出
选“自定义”导出却卡在“正在生成 SQL”不动
phpMyAdmin 默认对大表（尤其是 wp_posts、wp_postmeta）尝试全量 SELECT + 构建 INSERT，内存耗尽或超时就会假死。这不是 bug，是设计限制。
- 避开“全选表 → 导出”，改用分批导出：先勾选
wp_options、wp_users、wp_usermeta这类小表导出为.sql - 对大表（如
wp_posts）单独操作：进入该表 → “导出” → 格式选CSV或JSON（比 SQL 更轻量），勾选数据不勾结构，并启用使用逗号分隔符和包含列名 - 如果必须导 SQL，用命令行更可靠：
mysqldump -u root -p --single-transaction --skip-lock-tables your_wp_db > wp_dump.sql
导出的 SQL 文件无法在目标环境导入（报错 #1062、#1146 等）
WordPress 数据库常含插件自建表、缓存数据、重复主键，直接全库导出会把脏数据也带过去，导致导入失败或站点异常。
- 导出前先清理：在 phpMyAdmin 中运行
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%';，清掉瞬态缓存 - 跳过某些表：导出时取消勾选
wp_options中的wp_woocommerce_sessions、wp_ai1wm_backups等明显是临时/备份表 - 确保目标库字符集一致：源库若为
utf8mb4_unicode_ci，目标库建库时也要指定相同 collation，否则中文可能乱码或插入失败
导出文件体积远大于实际数据库大小
phpMyAdmin 默认导出包含大量 INSERT 语句和完整表结构，加上 WordPress 的冗余字段（如 post_content 中的 HTML、短代码），会导致 SQL 文件膨胀 2–3 倍。
- 导出格式优先选
CSV：只存纯数据，无 SQL 开销，体积通常只有 SQL 的 1/4 - 如需迁移，用
mysqldump加参数压缩：mysqldump -u user -p --no-create-info --skip-extended-insert your_db | gzip > dump.sql.gz（--skip-extended-insert减少语法冗余，--no-create-info跳过建表语句） - 注意：CSV 不含索引和外键，导入后需手动重建索引，否则查询会极慢
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
