“转储 SQL 文件”是唯一可行路径，因其完整导出跨库依赖对象（如视图、函数、事件、CREATE DATABASE语句），按依赖顺序排列，支持分表分库场景；而.nb3备份功能忽略跨库引用、跳过视图/函数/事件，还原时报Unknown database或Table doesn't exist。
不能用“备份”功能（.nb3）导出分表分库数据，它不识别跨库依赖、跳过视图/函数/事件，且还原时会报错 Unknown database 或 Table doesn't exist。
为什么“转储 SQL 文件”是唯一可行路径
分表分库场景下，业务逻辑常依赖跨数据库的视图、存储过程、触发器或外键（即使 MariaDB 不强制跨库外键，应用层仍可能假设存在）。Navicat 的 备份 功能只处理单库物理结构，对 CREATE VIEW v_user_order AS SELECT * FROM db_order.t_order JOIN db_user.t_user 这类语句直接忽略；而 转储 SQL 文件 会完整提取所有 CREATE 语句，并按依赖顺序排列。
常见错误现象包括：
- 还原时提示
ERROR 1049 (45000): Unknown database 'db_order'—— 因 .nb3 不导出CREATE DATABASE语句 - 还原后视图查不到数据，但表存在 —— 因
备份功能跳过视图定义 - 定时任务跑完没报错，但 backup.nb3 文件大小恒为 2KB —— 实际未写入任何内容
导出时必须手动勾选的三个关键选项
右键目标数据库 → 转储 SQL 文件 → 切换到 高级 选项卡：
- 勾选
添加 DROP TABLE IF EXISTS：避免还原时因表已存在中断流程 - 取消勾选
使用扩展插入：分表场景下单表可能超 100 万行，启用该选项易触发MySQL server has gone away（受max_allowed_packet限制） - 显式设置
字符集为utf8mb4：分库系统中用户表、日志表、配置表若混用latin1和utf8，不统一会导致还原后中文乱码且无法回溯
跨多个数据库导出的实操要点
Navicat for MariaDB 不支持一次选中多个数据库执行“转储 SQL 文件”，必须逐个操作。但顺序很重要：
- 先导出基础库（如
db_common，含公共函数、UDF、基础配置表） - 再导出业务库（如
db_user、db_order），确保其视图/存储过程引用的基础对象已存在 - 每个库导出时，在
常规选项卡中勾选包含 CREATE DATABASE 语句—— 否则还原脚本不会自动建库 - 文件命名建议带库名和时间戳：
db_user_202609072230.sql，避免混淆
导出后务必执行：grep -n "CREATE DATABASE" db_user_202609072230.sql，确认首行是建库语句；再用 head -n 50 db_user_202609072230.sql | grep "CREATE VIEW" 验证视图是否被包含。
备份后验证不能只看文件大小
分表分库的备份文件容易“看起来正常却实际残缺”。必须做两件事：
- 用
mysql -u root -p -e "source /path/to/db_user_202609072230.sql"在测试环境试还原，观察是否报ERROR 1146（表不存在）或ERROR 1356（视图定义不可用） - 还原后运行：
mysql -u root -p -D db_user -e "SHOW FULL TABLES WHERE Table_Type = 'VIEW';"，比对与原库输出是否一致
最容易被忽略的是：Navicat 导出时默认不包含 EVENT（事件调度器），哪怕你勾选了“结构和数据”。必须手动在 高级 选项卡中额外勾选 导出事件，否则定时清理任务类逻辑会丢失。
