Navicat 17批处理作业天生不支持并发，本质是串行执行器；所有任务按顺序逐个运行，无并行能力，真并发需依赖操作系统级工具（如crontab或Windows任务计划）调用独立备份命令实现。
Navicat 17 的批处理作业天生不支持并发
Navicat 17 没有“并发控制”这个概念——它的批处理作业（批处理作业）本质是 UI 封装的串行执行器，所有添加进去的任务按顺序一个接一个跑，中间不插队、不跳过、不并行。你看到多个备份或导出任务排在一起，只是列表顺序，不是调度队列。
常见错误现象包括：以为勾选了“共享连接”就能提速，结果因事务隔离或锁表导致后续任务卡住；或误以为“设置相同触发时间”会让多个任务同时启动，实际仍是单进程逐个调用。
-
批处理作业内部无线程池、无超时中断、无失败重试机制 - 每个任务启动新进程（如
mysqldump或pg_dump），但 Navicat 不管理这些子进程的生命周期 - 即使你建了 10 个独立的
批处理作业，Navicat 也不会自动并发执行它们——必须手动点 10 次「运行」
想真正并发，得绕开 Navicat 的 UI 层
真正的并发控制必须由操作系统级工具接管，Navicat 只负责生成可执行命令或脚本。关键不是“在 Navicat 里怎么设”，而是“怎么让系统同时跑多个备份/导出”。
使用场景：你需要在凌晨 2:00 同时对 MySQL@192.168.1.10、PostgreSQL@192.168.1.11、SQL Server@10.0.2.5 三个库做全量备份，总耗时从 45 分钟压到 18 分钟以内。
- Linux/macOS：用
crontab -e写三行独立命令，每行带&后台启动 +wait收尾（或用parallel） - Windows：在任务计划程序中创建三个独立任务，触发时间都设为 02:00:00，并确保「不管用户是否登录都要运行」已勾选
- 所有脚本中避免使用相对路径、环境变量（如
%date%）、明文密码；改用mysql_config_editor或.pgpass文件
并发时最容易被忽略的资源冲突点
并行不是越多越好。Navicat 自身不干预 I/O 或 CPU 调度，但底层数据库和磁盘会直接暴露瓶颈。
典型表现：并发数从 2 升到 4 后，总耗时反而增加 20%，日志里出现大量 Lock wait timeout exceeded 或 disk I/O wait。
- MySQL 备份并发超过 2 个时，
mysqldump --single-transaction可能因长事务阻塞其他备份 - 机械硬盘或 NFS 存储上，并发写入多个
.sql.gz文件极易引发 I/O 争抢 - PostgreSQL 的
pg_dump默认加ACCESS SHARE锁，高并发下可能触发锁升级或等待队列堆积 - Navicat 导出 CSV 并发执行时，若目标目录在 Windows 网络共享路径下，SMB 协议可能拒绝多客户端同时写入
如果非要用 Navicat 做“伪并发”，只能靠拆分+错峰
这不是真并发，但能在 Navicat 框架内尽量压缩窗口——适用于无法接触服务器命令行、只能用图形界面的受限环境。
核心思路：把原本塞进一个 批处理作业 的 5 个任务，拆成 3 个独立作业，再用系统调度器错开触发时间（比如 02:00:00、02:00:10、02:00:20），人为制造时间重叠。
- 每个
批处理作业仍串行执行，但三个作业的生命周期会部分重叠 - 需手动测试各任务平均耗时，预留至少 1.5 倍缓冲间隔，防止后一个作业启动时前一个还没释放连接
- 务必关闭所有作业的「共享连接」选项，否则跨作业的连接复用会引发事务污染或字符集错乱
- 这种做法无法监控子任务状态，任一失败都不会通知，也不记录 exit code —— 日志只能查 Navicat 主进程的
navicat.log，且不包含子命令输出
真正可控的并发永远不在 Navicat 界面里，而在你写的那几行 shell 或 PowerShell 脚本中。它不提供按钮，但给你全部权限：限速、重试、熔断、资源分组——这些 Navicat 故意没做的，恰恰是你该亲手补上的。
