Navicat 本身不支持定时执行 SQL 脚本，需借助系统计划任务调用其 CLI 工具实现自动化；脱敏与导出需封装为标准 SQL 脚本并配合事务、权限及验证逻辑，生产环境更推荐使用原生数据库工具。
Navicat 本身不支持定时执行 SQL 脚本
Navicat 是数据库客户端工具，不是调度引擎。它没有内置的定时任务功能，自动运行脚本 + 导出 这一整套流程无法仅靠 Navicat 界面完成。你看到的「计划任务」功能（如 Windows 的「计划程序」或 macOS 的 launchd）才是实际执行调度的载体。
用 Windows 计划任务调用 Navicat CLI 实现自动化
Navicat 提供命令行工具 navicat.exe（Windows）或 navicat（macOS/Linux），可执行连接、运行 SQL、导出等操作。关键在于把脱敏逻辑封装进 SQL 脚本，再让 CLI 按顺序执行：
-
navicat.exe必须安装完整版（非精简版），且路径需加入系统环境变量，或在计划任务中写绝对路径，例如："C:\Program Files\PremiumSoft\Navicat Premium 16\navicat.exe" - 脱敏 SQL 脚本（如
anonymize_users.sql）应使用标准 UPDATE/REPLACE/MD5 等语句，避免依赖 Navicat 特有函数（如navicat_encrypt()不存在） - 导出必须用
--export参数配合--export-file，且目标目录需提前存在、有写入权限；导出格式（CSV/Excel/SQL）由--export-format控制，例如--export-format CSV - 整个命令需串成单行，用
&&连接（Windows）或;（macOS/Linux），例如：navicat.exe --connection "my_db" --sql-file "anonymize_users.sql" && navicat.exe --connection "my_db" --export --export-file "D:\exports\users_anonymized.csv" --export-format CSV --table "users"
脱敏脚本里容易被忽略的事务与权限问题
直接在 CLI 中运行 UPDATE 类脱敏语句，默认不开启事务，一旦中途失败，数据可能处于半脱敏状态。务必在 SQL 脚本开头加上 START TRANSACTION;，结尾加 COMMIT; 或 ROLLBACK;（需配合错误处理逻辑）。
- Navicat CLI 执行 SQL 时，以连接配置中指定的用户身份运行，该用户必须有
UPDATE、SELECT和对应表的LOCK TABLES权限（MySQL）或EXECUTE（PostgreSQL 函数调用） - 如果脱敏涉及多表 JOIN 更新（如用
UPDATE t1 JOIN t2 ON ...），MySQL 语法允许，但 PostgreSQL 需改用UPDATE ... FROM，CLI 不做语法校验，出错只在运行时报ERROR 1064或ERROR 42703 - 导出前建议加一条验证查询，例如
SELECT COUNT(*) FROM users WHERE phone REGEXP '^[0-9]{11}$';，结果为 0 才说明脱敏生效，可配合 shell 脚本做简单断言
更可靠的做法：绕过 Navicat CLI，用原生数据库工具
Navicat CLI 兼容性有限，尤其对 MySQL 8.0+ 的 CTE 或 JSON 函数支持滞后，且日志输出不完整。生产环境建议改用数据库自带工具：
- MySQL：用
mysql客户端 +mysqldump，脱敏用UPDATE语句，导出用SELECT ... INTO OUTFILE或mysqldump --where="1=1"配合临时表 - PostgreSQL：用
psql -c "UPDATE ..."+pg_dump --table=users --inserts或COPY (SELECT ...) TO 'file.csv' - 所有操作统一用 shell/batch 脚本封装，再交由系统计划任务调度，可控性、可观测性和错误捕获能力远高于依赖 Navicat CLI
真正卡点往往不在“怎么写”，而在“谁来保证脱敏后数据不可逆、导出文件不残留临时字段、失败时不发通知也不留脏数据”——这些得靠脚本里的 set -e、rm -f、mail -s 这类细节补全，而不是指望 Navicat 点几下就搞定。
