navicat 不支持真正批量导出所有数据库为独立sql文件，其“批处理作业”需手动逐个配置连接与库名，不共享参数、无错误传递、无法自动遍历；可行方案是用mysql客户端配合shell/powershell脚本调用mysqldump逐库导出。
navicat 无法真正批量导出所有数据库为独立备份文件——它没有“一键遍历所有数据库并生成多个 .psc 或 .sql 文件”的功能。所谓“批量”，实际只是顺序执行多个硬编码的单库任务，且不共享连接、路径、参数或错误处理逻辑。
为什么「新建批处理作业」不能替代真正的批量备份
很多人点开「计划」→「新建批处理作业」后，以为可以统一配置、自动发现所有数据库，结果发现：每个条目都必须手动指定「连接名」和「数据库名」，例如：Backup hcpmanage (MySQL@192.168.1.10:3306) 和 Backup billing_db (MySQL@192.168.1.11:3306) 是两个完全独立的动作。它们之间：
- 不共享用户名/密码、导出路径、压缩设置或字符集选项
- 不会因前一个失败而跳过或重试，也不会聚合日志
- 若某台服务器连接超时或权限不足，后续任务照常触发，但静默失败
- 任务分组（拖拽到同一文件夹）仅是 UI 归类，不影响执行时的行为
想让每个数据库生成一个独立 SQL 文件，只能靠「转储SQL文件」逐个操作
Navicat 的 转储SQL文件 功能本身不支持“当前连接下所有数据库”一键触发。你必须：
- 手动展开每个数据库 → 右键 →
转储SQL文件→ 勾选「结构和数据」→ 指定唯一路径（如D:\backups\mydb_20260601.sql） - 无法用通配符（如
%.sql）或变量（如${DB_NAME}）自动命名，文件名需人工输入或提前规划 - 若数据库名含空格或中文，导出路径建议用英文+下划线，避免 CLI 调用时解析异常
- 导出大库时注意 Navicat 内存占用：默认加载全部结果再写入，可能卡死；可改用命令行
mysqldump分离执行
真正可行的批量方案：绕过 Navicat GUI，用系统级脚本驱动
生产环境多库备份必须脱离 Navicat 图形界面。推荐组合使用 mysql 客户端 + shell/PowerShell 脚本，例如 Linux 下：
mysql -u root -p -Nse "SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME NOT IN ('information_schema','mysql','performance_schema','sys')" | while read db; do
mysqldump -u root -p --single-transaction --routines --events "$db" > "/backup/$db_$(date +%Y%m%d).sql"
done
关键点：
-
mysqldump支持--routines（存储过程）、--events（事件），补齐 Navicat转储SQL文件缺失的元数据 - Navicat 的
.psc备份包不可读、不可审计、无法用 diff 工具比对，而纯 SQL 文件可版本控制、可 grep 检查 - 脚本可加入
if [ -f ... ]判断、rsync推送、find /backup -mtime +7 -delete清理，Navicat 任务计划做不到 - Windows 用户可用 PowerShell 替代，但注意
navicat.exe /exportCLI 模式不支持跨库循环，仍需先查库名再调用多次
最易被忽略的一点：Navicat 后台任务运行在 Windows 服务上下文（如 LocalSystem），它看不到用户会话中映射的网络盘符（如 Z:\backup），也常因 UAC 或防火墙拦截 SSH 隧道导致远程库备份失败——这些故障在图形界面里只显示「Lost connection」，无具体错误码，排查成本远高于直接跑脚本看 stderr 输出。
