Navicat所有同步操作均为单线程执行，所谓“并发连接数”仅控制同时打开的连接数量，并非真正并行处理；实际逻辑仍由单主线程串行调度，无法突破单核瓶颈，大表同步应改用mysqldump+parallel等原生并行工具。
navicat 本身不支持多线程同步大表数据——它所有同步操作（data synchronization、data transfer）均单线程执行，无论你勾选多少“并发”选项，底层仍是串行拉取+拼sql+逐批提交。
为什么 Navicat 界面里有“并发连接数”却不起作用？
这是最容易被误导的点。Navicat 的“并发连接数”设置（如在 Data Transfer 高级选项中）仅控制**同时打开的数据库连接数量**，并非真正意义上的并行处理线程。实际同步逻辑仍由单个主线程调度：它会按顺序从源库读取一批数据 → 转换 → 发送到目标库 → 等待返回 → 再读下一批。即使开了 4 个连接，也只是让这 4 个连接轮流排队干活，不是四路并进。
- 实测表现：对一张 500 万行的表，设并发为 1 或 4，总耗时几乎无差别，CPU 占用始终单核打满
- 根本原因：Navicat 同步引擎基于 Qt SQL 模块封装，未做异步 I/O 或 worker pool 设计，无法突破单线程瓶颈
- 官方文档从未承诺“多线程同步”，所有宣传中的“高速”均指优化单线程路径（如压缩、批量、Server export），而非并行化
真正能加速大表同步的替代方案
绕过 Navicat GUI，用原生工具链实现真实并行：
-
mysqldump+mysql：用mysqldump --where="id BETWEEN 1 AND 1000000"分段导出多个文件，再用parallel -j 4 mysql -u user -p db < {}并行导入（Linux/macOS） -
pg_dump+pg_restore：加-j 4参数直接启用 4 线程并行 dump/restore（PostgreSQL 原生支持） - MySQL 8.0+ 的
LOAD DATA INFILE+CONCURRENT：先用SELECT ... INTO OUTFILE导出多个分片文件，再用LOAD DATA CONCURRENT INFILE并行加载（需目标表引擎支持） - 避免跨网段中转：用
ssh管道直连，如mysqldump -h src_db ... | ssh user@dst "mysql -h localhost ..."，省去本地磁盘 IO 和内存缓冲
Navicat 内部能调的唯一“伪并发”参数
如果你必须坚持用 Navicat GUI，唯一可调的性能杠杆是 **Batch size** 和 **Commit every batch**，但它们不等于多线程：
- Batch size 设为
50000（非100）：减少网络往返和事务开销，但单批过大可能触发max_allowed_packet或内存溢出 - 取消勾选
Commit every batch：让整个同步过程只 commit 一次，大幅降低日志刷盘频率 - 务必启用
Use compression（连接设置 → Connection 标签）：对 TEXT/JSON 字段多的表，压缩后传输量下降 40%～70%，等效提升带宽利用率 - 禁用
Compare records row by row：改用主键比对，否则 10 万行以上就卡死，且跨库时类型微差会导致全量重传
真正的大表同步，从来不是靠“开启多线程开关”解决的——而是把任务拆到系统层，用原生工具跑并行，再把 Navicat 当作配置界面和状态看板来用。它擅长可视化和调试，不擅长吞吐密集型任务。
