navicat 的 scheduler 无法共享维护计划，因其任务仅本地存储、不跨用户同步；团队协作需依托 on-prem server 共享 sql 脚本，并注意路径变量、use 显式指定库、权限配置三坑。
navicat 本身不支持“团队共享的维护计划”这个概念——scheduler 里的任务是本地客户端级的，每个用户在自己机器上创建的任务，不会自动同步给其他人。
为什么 Navicat 的 scheduler 无法直接共享维护计划
Navicat 的 scheduler 功能（右键数据库 → Scheduler → 新建任务）本质是调用本地 Navicat 进程执行 SQL 或备份操作，所有任务配置、触发时间、日志都只保存在当前用户的 Navicat 安装目录下（如 Windows 的 %AppData%\PremierSoft\Navicat\）。即使多人连接同一个数据库，各自创建的 scheduler 任务也完全隔离。
- 你设了每天凌晨 2 点备份，同事的 Navicat 不会知道这件事
- 任务失败时，只有你本机能看到错误日志，比如
Failed to execute backup: Permission denied on target path - 没有版本控制、没有审批流、无法审计谁改过哪个任务
真正能团队共享的维护逻辑，必须走 On-Prem Server + 查询/代码段
如果你用的是 Navicat Premium 17 或更高版本，并已部署 Navicat On-Prem Server，那共享维护能力就落在「可复用的 SQL 脚本」上，而不是 scheduler 本身。
- 把备份、表优化、索引检查等逻辑写成标准
.sql文件，例如mysql_daily_maintenance.sql - 将该文件保存为 On-Prem Server 上的共享
查询或代码段，所有成员都能看到、运行、编辑（需权限） - 每个 DBA 在自己机器上新建一个
scheduler任务，但操作类型选「运行查询」，再从 On-Prem Server 中选择那个共享查询 - 这样，维护逻辑统一在服务器端管理，调度行为仍本地化，但核心脚本具备协同性与可追溯性
实际配置中容易被忽略的三个坑
即使走 On-Prem Server 共享查询，以下细节不处理好，团队协作照样失效：
-
路径硬编码：SQL 脚本里写死INTO OUTFILE '/tmp/backup_20260603.sql'，不同人执行会因权限或路径不存在而失败；应改用变量或由客户端传参（如 Navicat 的@param） -
数据库连接上下文错乱：共享查询默认绑定创建时的连接，拖到 On-Prem Server 后，其他人在不同连接下双击运行，可能连错库；务必在查询开头加USE `target_db`;显式指定 -
On-Prem Server 权限未细化：默认项目成员有「查看+运行」权限，但没「编辑」权限；如果想让值班 DBA 能临时调整维护脚本，需在 On-Prem Server 后台为对应角色开启Query Editor权限
真正的难点不在怎么点几下鼠标，而在于把“谁在什么时候改了哪条维护语句”变成可追踪、可回滚、可验证的行为——这需要把 SQL 当代码管，不是当配置项抄。
