导出WordPress 6.0多站点数据库必须包含wp_blogs、wp_site、wp_sitemeta及所有wp_X_*子表；需用phpMyAdmin“自定义”导出并勾选DROP语句、结构与数据，或改用mysqldump命令确保一致性。
导出前先确认数据库结构是否含多站点表
WordPress 6.0 多站点（Multisite）启用后，数据库里不会新增独立的“多站点库”，而是在原数据库中扩展出带 wp_ 前缀的额外表（如 wp_blogs、wp_site、wp_sitemeta），以及按站点 ID 生成的子表（如 wp_2_posts、wp_3_options）。如果你只导出了 wp_posts、wp_options 这类主站表，就等于漏掉了全部子站点数据。
操作前务必：登录 phpMyAdmin → 左侧选中你的数据库 → 滚动查看所有表名，确认存在 wp_blogs 和至少一个数字编号的表（如 wp_2_users）。没有这些，说明没真正启用多站点，或网络未正确配置。
导出时必须选“自定义”，且勾全关键选项
“快速”导出模式默认只导出结构+数据，但对多站点来说，它会跳过部分系统表，且不生成 DROP TABLE 语句——这会导致恢复时表冲突或插入失败。你得用“自定义”导出，并手动核对以下几项：
- 在“导出方式”区域，勾选
添加 DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT 语句 - 在“对象”区域，确保
结构和数据都被勾选 - 在“表”列表中，**不要取消任何以
wp_开头的表**（包括wp_2_*、wp_3_*等）；若看到插件创建的非 wp 前缀表（如wpml_*），可酌情排除，但不确定就留着 - 在“输出”区域，选中
保存输出到文件，压缩格式选gzip（比 zip 更小，适合大库） - 在“SQL 兼容性”下拉菜单中，选
MYSQL40或留空（WordPress 6.0 官方推荐兼容模式为MYSQL57或更高，但跨环境迁移时MYSQL40反而更稳）
备份后要检查 .sql 文件里有没有多站点核心表
下载完 backup-20260915.sql.gz 后，别急着删源库。用文本编辑器（如 VS Code）解压并打开，搜索几个关键词验证是否完整：
立即学习“PHP免费学习笔记（深入）”；
中文敏感词/违禁词检测与内容合规性检查工具。支持对小红书（Xiaohongshu）、Douyin（抖音）、WeChat（微信）、Weibo（微博）、Bilibili（哔哩哔哩）、Zhihu（知乎）、Taobao（淘宝）、JD.com（京东）等主流平台的禁用词、限用词及高风险词进行文本扫描与合规性分析。
- 搜
CREATE TABLE `wp_blogs`—— 必须存在，这是多站点网络的根表 - 搜
CREATE TABLE `wp_2_options`（把 2 换成你实际的子站点 ID）—— 至少有一个数字编号表被导出 - 搜
INSERT INTO `wp_site`—— 应有至少一行插入语句，包含主站点域名
如果任意一项没找到，说明导出时漏选了表，或者 phpMyAdmin 页面因超时中断（常见于大库），此时应改用 mysqldump 命令行方式重备。
用 mysqldump 替代 phpMyAdmin 导出大库更可靠
当你的多站点数据库超过 50MB，phpMyAdmin 很容易在导出中途报错：Maximum execution time of 300 seconds exceeded 或 upload_max_filesize exceeded。这时直接上命令行最省事：
mysqldump -u<code>your_db_user</code> -p<code>your_db_password</code> --single-transaction --routines --triggers <code>your_db_name</code> > <code>multisite-backup.sql</code>
说明：
-
--single-transaction能保证多站点各表导出时数据一致（避免导出过程中子站点正在写入导致状态错乱） -
--routines和--triggers保留存储过程和触发器（某些多站点插件依赖它们） - 不加
--compress，导出后手动gzip multisite-backup.sql更可控 - 执行后输入密码，生成的
multisite-backup.sql是纯文本，可直接用上面的搜索法验内容
多站点数据库备份最易忽略的点，不是“怎么导”，而是“导了哪些表”——只要漏掉 wp_blogs 或任一 wp_X_* 表，整个子站点就无法恢复。所以每次备份后花 30 秒 grep 一下，比事后重建网络省三天。
