Navicat 16不支持真正实时同步，其“双向同步”实为两次定时轮询式单向同步，依赖主键比对生成INSERT/UPDATE语句，无CDC或WAL日志监听能力，延迟秒级至分钟级，且无断点续传与状态跟踪。
navicat 16 本身不支持真正意义上的实时数据流备份——它没有内置的 cdc（change data capture）或 wal 日志订阅能力。所谓“实时同步”，实际是定时轮询 + 差异比对，延迟通常在秒级到分钟级，取决于配置和数据量。
如果你看到“实时副本”效果，大概率是误判了同步频率，或混淆了 Navicat 的 数据同步 功能与数据库原生复制（如 MySQL 的主从、PostgreSQL 的逻辑复制）。
为什么 数据同步 不等于实时备份
Navicat 的 数据同步 是一次性、手动或计划触发的操作，底层执行的是：SELECT 源表 → 比对主键/唯一键 → 生成 INSERT/UPDATE/DELETE 语句 → 执行到目标库。整个过程无状态、无增量日志跟踪：
- 不会监听 binlog 或 wal，无法捕获事务中间态
- 两次同步之间发生的多次变更，只会被合并为一次最终状态覆盖
- 若源表无主键或唯一键，
数据同步会退化为全量比对，性能陡降且无法识别行级变更 - 同步任务失败时，不会自动重试或断点续传，需人工介入
如何把 数据同步 配置得“尽量接近实时”
虽然达不到毫秒级，但可通过高频计划 + 合理参数压缩延迟窗口：
- 在
计划任务中设置间隔为1 分钟（最小支持值），注意：过于频繁可能引发锁竞争或连接耗尽 - 勾选
仅同步已更改的记录，并确保源/目标表都有高效索引支撑主键比对 - 禁用
验证数据一致性（默认开启），该选项会额外执行全表校验，大幅拖慢同步速度 - 目标库连接使用
专用只写账号，避免权限检查开销；源库账号需有SELECT权限，无需LOCK TABLES - 大表同步前，在高级选项中启用
分批处理（如每批 5000 行），防止单次事务过大导致超时或锁表
遇到 同步中断后数据不一致 怎么办
这是高频使用场景下的典型问题——比如网络抖动、目标库短暂不可达、某条 UPDATE 因约束冲突失败。Navicat 不记录同步位点，因此：
- 失败任务不会自动标记“已部分完成”，重跑会重复应用已成功语句，可能引发主键冲突或数据覆盖
- 必须人工检查日志中最后成功的
SQL语句，定位断点；或清空目标表重新全量同步（仅适用于小表） - 更稳妥的做法：在源库加一个
updated_at时间戳字段，并在同步条件里加上WHERE updated_at > ?，配合外部脚本维护上次同步时间 - 不要依赖
同步日志窗口里的简略输出，关键要导出完整日志（右键 →导出日志），搜索ERROR和Failed
真正需要实时副本？绕过 Navicat 直接用数据库原生机制
如果业务要求亚秒级延迟、事务一致性、故障自动恢复，Navicat 数据同步 是错误工具：
- MySQL：配
主从复制（基于 binlog），从库可设为read_only=ON做只读副本 - PostgreSQL：用
logical replication（10+ 版本），支持按表订阅，延迟通常 - SQL Server：启用
Always On 可用性组或事务复制 - 所有方案共性：不依赖客户端轮询，直接消费服务端日志，且能保留事务边界
Navicat 此时只适合做初始化迁移、周期性校验或非关键数据的离线归档。
