Navicat无法真正实现多个分支机构数据的定时汇总，因其批处理作业不支持跨连接聚合、结构自动适配及冲突去重；必须将汇总逻辑下沉至数据库端（如存储过程），Navicat仅负责调用触发。
Navicat 无法真正实现“多个分支机构数据的定时汇总”——它的批处理作业只是顺序执行多个已配置任务，不支持跨连接聚合、不自动适配不同结构、也不处理冲突或去重逻辑。真要汇总，必须把核心逻辑下沉到数据库内（如用存储过程拉取各源库数据），再让 Navicat 仅负责触发和调度。
为什么直接用 Navicat 批处理做跨库汇总会失败
常见错误现象：作业显示“运行成功”，但目标表数据为空或只有部分分支数据；某一分支库连接超时后，后续步骤直接跳过，无日志提示；字段名相同但类型不一致（比如 branch_id 在 A 库是 INT，在 B 库是 VARCHAR），导致 INSERT 失败且 Navicat 不报具体 SQL 错误。
- Navicat 批处理中每个「运行查询」步骤绑定唯一连接，不能动态切换源库——你得为每个分支单独建一个查询（如
fetch_from_beijing、fetch_from_shanghai），再手动加进批处理 - 它不提供
INSERT INTO ... SELECT FROM remote_db.table这类跨连接语法支持；MySQL 需 FEDERATED 表，PostgreSQL 需 postgres_fdw，而 Navicat 不帮你建这些外部表 - 即使所有查询都写成
INSERT INTO summary_table SELECT * FROM local_temp，也默认不开启事务，网络中断时可能只插入了前两库，后三库静默丢失 - 日期参数无法自动替换：你想每天汇总
WHERE create_time > CURDATE() - INTERVAL 1 DAY，但 Navicat 不支持在批处理里传参或计算时间，只能写死或靠数据库函数
可行路径：用存储过程封装汇总逻辑，Navicat 只调用一次
这是生产环境最可控的做法。把“连 A 库取数 → 连 B 库取数 → 去重合并 → 写入汇总表”全部写进数据库端的存储过程中，Navicat 批处理只执行一条 CALL merge_branch_data()。
- MySQL 示例：在中心库创建
merge_branch_data存储过程，内部用INSERT INTO ... SELECT拉取各分支库（需提前建好 FEDERATED 表或用mysql://链接） - PostgreSQL 示例：用
postgres_fdw创建 server + foreign table，再在merge_branch_data()里做 UNION ALL 和 ON CONFLICT DO UPDATE - Navicat 中新建批处理作业，只添加一个「运行查询」步骤，内容为
CALL merge_branch_data()或SELECT merge_branch_data()（取决于返回类型） - 务必在存储过程开头加
SET SESSION lock_timeout = '30s';，避免某一分支库锁表导致整个汇总卡住
若必须用 Navicat 批处理串联多个查询，这些参数必须改
如果你坚持用纯 Navicat 方式（例如分支库无法开远程访问权限，只能本地导出再导入），以下设置能减少翻车概率：
- 每个「运行查询」步骤右侧齿轮 → 「高级」→ 勾选
忽略错误：防止某一分支库临时不可达导致后续全停 - 超时时间统一设为
600秒以上：分支库响应慢很常见，300 秒默认值不够 - 日志级别设为
详细：否则你看不到哪一步的Lost connection或Unknown column - 禁用「共享连接」：每个查询用独立连接，避免
SET sql_mode或时区设置互相污染 - 不要在批处理里用
TRUNCATE summary_table开头——万一中间失败，数据就没了；改用DELETE FROM summary_table WHERE batch_date = CURDATE()，保留历史可回溯
真正难的不是点几下鼠标配个批处理，而是确认各分支库的表结构是否长期一致、网络是否稳定、权限是否最小化、以及失败后能否快速定位是哪个库哪条语句挂了。Navicat 的日志只告诉你“第 3 步失败”，不会告诉你失败时实际发给数据库的是哪条 SQL——这点最容易被忽略。
