Navicat定时同步卡住根本原因是GUI进程被子任务阻塞，而非崩溃；其默认图形化调用mysqldump等工具，依赖进程通信与状态轮询，子进程不主动输出日志时主界面便无响应，实际磁盘I/O持续运行。
navicat定时数据同步任务卡住，90%以上不是配置没保存或网络不通，而是它在后台默默执行着，但主界面完全不反馈进度——你看到的“卡住”，其实是navicat的gui进程被子任务阻塞，根本没崩，只是不说话。
为什么“正在执行中”一动不动？
Navicat默认用图形界面方式调用mysqldump、pg_dump或内部同步引擎，全程依赖进程间通信+日志重定向+轮询状态。一旦子进程（比如导出百万行）不主动刷stdout，Navicat主进程就干等，直到超时才报错。此时任务管理器里Navicat进程CPU可能只有5%，但磁盘I/O持续跑满——它真在干活，只是不告诉你。
- 典型表现：
mysqldump命令在终端里10秒能跑完，Navicat里卡3分钟无响应 - 日志里反复出现
java.net.SocketException: Broken pipe或Too many open files，说明系统资源已耗尽 - 备份路径设在
~/Documents/Navicat/Backup这类系统盘路径，SSD写入队列堵死
同步卡在“Comparing records”阶段CPU飙高
这阶段Navicat不走数据库索引，而是把整张表SELECT *拉到本地内存做哈希比对。只要源表或目标表缺主键，或两边UNIQUE NOT NULL索引字段顺序/字符集不一致，它就自动降级为全量加载+排序。
- 用
SHOW CREATE TABLE table_name分别查两边结构，重点比对：PRIMARY KEY是否存在且字段顺序一致、COLLATE是否相同、索引名是否完全匹配 - Navicat日志里如果高频出现
SELECT * FROM `xxx`，基本确认已进入全量拉取模式 - 并发线程数设成8或16反而更慢：本地连接池、MySQL的
max_connections、Linux临时端口范围（/proc/sys/net/ipv4/ip_local_port_range）全会成为瓶颈
定时任务本身就不支持断点续传
Navicat所有同步任务（包括定时触发的）一旦中断，不会记住“已同步到第几行”，而是从头再来。如果你的定时任务每小时跑一次，但每次都要花25分钟，而它在第24分钟断了——下次还是从第一行开始，永远追不上。
- 检查同步日志末尾是否有
Connection reset by peer或Lost connection to MySQL server，这是源库wait_timeout太短导致的主动断连 - 必须同时调高MySQL服务端的
wait_timeout和interactive_timeout（建议设为86400），并关闭Navicat连接设置里的自动断开空闲连接 - 如果用SSH隧道，
ServerAliveInterval必须设为≤30秒，否则跳板机先把你掐了
别信“添加到计划”按钮，它大概率是灰色的
Navicat 15及更早版本的「数据同步」功能，只有Navicat Premium在有效授权下才支持内置计划模块。Essentials、Standard、甚至未激活的Premium，这个按钮都是禁用状态——你点不动，不是操作错，是压根没权限。
- 真正能跑定时任务的方式只有一种：用命令行调用已保存的
.ncx文件，再套系统计划任务 - Windows示例：
navicat.exe --sync "C:\Tasks\sync.ncx"；macOS示例：/Applications/Navicat\ Premium.app/Contents/MacOS/navicat --sync "/Users/me/sync.ncx" - 务必勾选同步设置里的
隐藏进度窗口，否则每次触发都会弹GUI窗，后台任务直接失败
最顽固的卡点往往不在Navicat设置里，而在表结构本身：无主键的大表同步，无论你怎么调线程、改超时、换磁盘，它都得全量拉取+内存排序。这点容易被忽略，但却是CPU长期100%、任务永远跑不完的根源。
