备份文件名必须显式包含Schema名或按Schema分目录存放，否则还原时无法区分同名表所属的Schema；Navicat默认不支持自动添加Schema名，需手动修改配置文件名或使用mysqldump命令自定义命名。
备份时文件名不带Schema信息，还原容易搞混
navicat 默认的自动备份任务（比如通过「自动运行」→「新建批处理作业」）生成的备份文件名只含数据库名和时间戳，例如 test-backup_202605071320.sql。如果多个 schema（如 tenant_a、tenant_b）下都有 users 表，且你用的是同一套备份脚本或计划，那所有备份都会落到同一个文件名模式里——还原时根本分不清哪个是哪个 schema 的数据。
手动改备份文件名是最直接可控的方式
Navicat 本身不提供「自动在文件名中插入当前 Schema 名」的选项，但你可以通过以下方式补救：
- 在「新建批处理作业」中选中目标 Schema 后，点击「保存」前，手动修改下方「配置文件名」字段：比如把默认的
test-backup改成tenant_a_test-backup或schema_tenant_a_users - 导出时勾选「使用时间戳」，Navicat 会自动拼在后面，最终得到类似
tenant_a_test-backup_202605071320.sql的文件名 - 如果用命令行配合 mysqldump（比如在 Navicat 的「工具」→「命令行界面」里调用），可直接控制输出路径和文件名：
mysqldump -u root -p tenant_a users > /backup/tenant_a_users_$(date +\%Y\%m\%d).sql
别依赖备份文件里的 SQL 注释来识别 Schema
虽然 mysqldump 生成的 SQL 文件开头通常有类似 -- Host: localhost Database: tenant_a 的注释，但这些内容不会出现在文件名里，也不被 Navicat 的「还原」界面解析。你无法靠双击打开一个 backup_20260507.sql 就知道它对应哪个 Schema——尤其当多个备份文件堆在一起时，人工翻注释效率低、易出错。
Schema 名必须显式出现在文件路径或文件名中
真正可靠的区分方式只有两种：
- 按 Schema 分目录存放：例如
/backup/tenant_a/users.sql、/backup/tenant_b/users.sql，路径本身就是上下文 - 在文件名中固化 Schema 名：如
bak_tenant_a_users_20260507.sql，注意这里用bak_前缀符合 DBA 规范，日期格式也严格用yyyymmdd（不能带横杠，否则 MySQL 解析报错）
哪怕只是临时备份调试用，也建议养成这个习惯——因为一旦哪天误删了 bak_users_20260507.sql，你根本没法确定它到底是哪个租户的数据。
