navicat 16批处理作业不支持嵌入清洗逻辑，仅能调度预定义操作；所有数据清洗必须提前写入utf-8无bom编码的.sql文件，用标准mysql语句实现，并按序调用多个文件，每个文件需显式事务控制。
navicat 16 的批处理作业本身不支持嵌入清洗逻辑，它只负责调度「已定义好的操作」——比如备份、还原、sql 文件执行。真要跑数据清洗流水线，必须把清洗动作拆解成可被批处理调用的独立单元。
批处理作业只能调用 SQL 脚本，不能直接写清洗逻辑
批处理作业界面里，“可用的工作”列表中出现的 Backup hh-vue 或 Run SQL File 这类条目，本质是 Navicat 封装好的原子操作。它不提供字段映射、正则替换、空值填充等清洗能力。所有清洗必须提前写进 .sql 文件里，再让批处理去触发执行。
- 你无法在批处理设置页里点击“添加清洗步骤”或配置“去除电话号码中的横线”
- 所有清洗动作必须转换为标准 SQL（MySQL 兼容），例如：
UPDATE user_log SET phone = REPLACE(REPLACE(phone, '-', ''), ' ', '') WHERE phone IS NOT NULL; - 复杂逻辑（如分组聚合后更新）需拆成多条语句，用事务包裹，避免中途失败导致脏数据
清洗脚本必须手动预编译，且注意 MySQL 版本兼容性
Navicat 16 执行 SQL 文件时，用的是当前连接所指向的 MySQL 服务端版本的解析器。这意味着你写的清洗语句，必须能在目标 MySQL 版本上直接运行，不能依赖 Navicat 自带的“导入向导”里的可视化转换功能（那部分逻辑不进批处理）。
- 避免使用 MySQL 8.0+ 的窗口函数（如
ROW_NUMBER()）清洗旧版数据库；检查目标环境是否开启ONLY_FULL_GROUP_BY，否则GROUP BY后的SELECT *会报错 - 日期转换要显式指定格式：用
STR_TO_DATE('20230101', '%Y%m%d')而不是依赖隐式转换，后者在 strict mode 下会失败 - 批量更新前务必加
WHERE条件，且建议先用SELECT COUNT(*)验证范围——批处理一旦启动，不会弹窗确认
真实流水线需要组合多个 SQL 文件 + 外部协调
一个典型清洗流水线（比如淘宝行为日志入库）包含：空值标记 → 时间戳标准化 → 重复键去重 → 异常值过滤 → 分区归档。Navicat 批处理无法在一个作业里串起这五步，但可以按顺序调用五个独立的 .sql 文件。
- 每个
.sql文件应只做一件事，并以/* STEP: clean_nulls */开头注释，方便定位失败环节 - 文件命名需带序号和意图，如
01_mark_nulls.sql、02_normalize_time.sql，避免依赖执行顺序出错 - 若某步失败（比如日志里出现
ERROR 1292 (22007): Incorrect datetime value），批处理会停止，但不会回滚前面已执行的步骤——必须在每个 SQL 文件开头手动加START TRANSACTION;，结尾加COMMIT;或ROLLBACK;判断
最容易被忽略的坑：权限、路径、字符集
批处理作业执行时，是以你 Navicat 当前连接的用户身份运行 SQL 的。这个用户必须有对应库表的 UPDATE、ALTER、EXECUTE 权限，而不仅仅是 SELECT。另外，SQL 文件里的路径（如 LOAD DATA LOCAL INFILE）是 Navicat 客户端所在机器的路径，不是服务器路径；文件编码必须是 UTF-8 无 BOM，否则中文字段名会变成乱码导致语法错误。
