Navicat自动化任务不检测并发冲突，所谓“冲突”实为MySQL层锁等待、死锁或外键失败；其日志不记录SQL错误详情，“成功”仅表示脚本发出，真实错误需查同步窗口日志详情、information_schema.INNODB_TRX或general_log。
navicat 自动化任务本身不检测并发冲突，所谓“任务冲突”其实是多个实例同时操作同一张表或数据库时，由 mysql 层面报出的锁等待、死锁或外键约束失败等错误——navicat.exe -runjob 启动的任务之间互不可见，也不会排队。
为什么 Navicat 任务日志里查不到“冲突”字样
Navicat 的「历史日志」（Ctrl+H）只记录客户端本地的操作时间戳，比如2026-04-25 04:30 执行了 Data Synchronization，它不捕获数据库返回的 SQL 错误详情，更不会标注“该任务被另一个任务阻塞”。你看到的“成功”，可能只是 Navicat 认为脚本发出去了，而 MySQL 实际执行时已因锁超时或主键重复静默失败。
- 同步任务若中途报错如
Lock wait timeout exceeded或Deadlock found when trying to get lock，这些信息只出现在 Navicat 同步窗口底部的「日志详情」面板里，且默认折叠，需手动点开才能看到 - 如果用命令行跑
navicat -runjob task.ncx，错误不会输出到终端，除非你在任务设置里勾选了「将日志保存到文件」并指定了路径 - Windows 任务计划程序调用时，若没勾选「不管用户是否登录都要运行」，任务会在后台以受限权限运行，连基本的连接都可能失败，但日志里只显示
Failed to load job，掩盖了真实原因
真正能定位并发冲突的三个关键位置
别盯着 Navicat 日志翻，直接查数据库和系统层：
- MySQL 的
information_schema.INNODB_TRX：执行SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 5，看是否有长时间未提交的事务卡住其他任务 - MySQL 的 general_log（需提前开启）：它会记录所有到达数据库的语句，包括两个 Navicat 任务发来的 INSERT。搜索关键词
INSERT INTO orders，对比时间戳，就能看出是否重叠执行 - Navicat 同步任务里的「高级」→「SQL 选项」→「设置时间戳字段为 CURRENT_TIMESTAMP」：如果多个任务同时更新同一张表的
updated_at字段，又没加 WHERE 条件，就会互相覆盖——这不是 Navicat 冲突，是业务逻辑缺陷
如何验证是不是真并发冲突，而不是配置问题
最简单的隔离测试法：
- 先停掉所有定时任务，只手动在 Navicat GUI 里跑一次同步，确认能成功
- 再用命令行单独执行一次：
navicat -runjob "C:\sync\task.ncx"，观察是否报错；如果成功，说明不是脚本问题 - 最后，在 Windows 任务计划程序里新建一个“立即运行”的任务，不设触发器，只测试单次执行。若失败，重点检查该任务的「安全选项」里是否勾选了「使用最高权限运行」和「不管用户是否登录都要运行」
- 如果以上都通，再恢复定时调度——此时若出问题，90% 是两个任务执行窗口重叠（比如 A 任务耗时 8 分钟，B 任务每 5 分钟触发一次），必须拉长间隔或加互斥锁（例如用
SELECT GET_LOCK('sync_orders', 0)）
Navicat 不提供任务队列或锁机制，所谓“冲突排查”，本质是把它的黑盒操作拆解成 MySQL 可观测行为。最容易被忽略的是：命令行任务和 GUI 任务用的是两套连接参数，前者默认不读取 GUI 里配置的「SSL 设置」「字符集」或「SQL mode」，这些差异常导致同一任务在 GUI 成功、命令行失败。
