WordPress导入大SQL失败主因是MySQL的max_allowed_packet和PHP的upload_max_filesize限制；需同步调高两者，并分表导出、用wp-cli导入，同时必须备份wp-content目录。
WordPress 导入数据库超 2MB 就报错？max_allowed_packet 和 upload_max_filesize 是真凶
wordpress 后台导入 sql 文件失败，常见错误是“文件过大”或直接白屏，根本不是 wordpress 本身限制，而是底层 mysql 和 php 的双层拦截。mysql 拒绝接收超过 max_allowed_packet 的单次查询（比如一条超长 insert），php 则在上传阶段就卡死于 upload_max_filesize 和 post_max_size。
实操建议：
- 先查当前值：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"，常见默认是 4M，但大站导出的单表 INSERT 可能轻松破 10M - 临时调高（重启后失效）：
SET GLOBAL max_allowed_packet = 64*1024*1024;（64MB） - 永久生效要改 MySQL 配置文件（如
/etc/mysql/my.cnf），在[mysqld]下加max_allowed_packet = 64M - PHP 端同步调整
upload_max_filesize、post_max_size、max_execution_time，否则文件传不上去，连碰 MySQL 的机会都没有
用 mysqldump 分表导出，别硬扛单文件
不分表硬导全库，一个 wp_posts 表就能占几百 MB，后续导入几乎必崩。分表不是为了“好看”，是让每个文件可控、可重试、可并行处理。
实操建议：
- 导出单表：
mysqldump -u user -p database_name wp_posts > wp_posts.sql - 跳过大表数据只导结构：
mysqldump -u user -p --no-data database_name wp_posts > wp_posts_structure.sql - 导出时压缩：
mysqldump -u user -p database_name wp_posts | gzip > wp_posts.sql.gz，再用zcat wp_posts.sql.gz | mysql -u user -p database_name导入，省带宽也减内存压力 - 避免导出
wp_options中的 transient 类垃圾数据：mysqldump -u user -p --ignore-table=database_name.wp_options database_name，之后单独清理再导入
wp-cli 导入大 SQL 更稳，比后台和 phpMyAdmin 少一层代理
WordPress 后台依赖浏览器上传 + PHP 执行，phpMyAdmin 还多一层 Web 服务器转发，每层都可能截断或超时。而 wp-cli 直连 MySQL，绕过所有 HTTP 层，对大文件更“钝感”。
实操建议：
- 确认已安装并可用：
wp --info，确保显示 MySQL 信息 - 导入前清空目标库（谨慎！）：
wp db reset --yes，再执行wp db import backup.sql - 如果仍报错
MySQL server has gone away，大概率是wait_timeout太短，临时设为 300：mysql -u user -p -e "SET SESSION wait_timeout = 300;" - 不推荐用
wp db import导入含DROP TABLE的全量 dump——它不会自动创建数据库，且遇到不存在的表会中断；更适合导入分表后的干净INSERT文件
备份策略里漏掉 wp-content 就等于没备份
数据库只是半边身子。主题、插件、上传的图片、自定义字段附件——全在 wp-content 目录里。只备份数据库，恢复后网站是空壳，前台 404，后台一堆“主题缺失”警告。
实操建议：
- 打包必须包含：
wp-content/themes/、wp-content/plugins/、wp-content/uploads/，忽略wp-content/cache/和wp-content/upgrade/ - 用
rsync增量同步比全量 tar 更省时间：rsync -avz --delete ./wp-content/ user@server:/path/to/wp-content/ - 数据库备份和文件备份**不能同频**：上传目录每天变，数据库可以每小时 dump 一次；混在一起做定时任务，容易误删或覆盖
- 恢复时顺序不能错：先还原
wp-content，再还原数据库，最后检查wp-config.php里的DB_NAME、table_prefix是否匹配
真正麻烦的从来不是“怎么分表”，而是恢复时发现 wp-content/uploads/2023/05/ 里那张活动海报根本不在最近一次备份里——因为没人定期验证备份可读性。
