navicat“数据传输”不是热备份，而是冷快照式迁移：它不加全局锁、无事务一致性保障、不记录binlog/lsn、无断点续传，仅适用于低频、可控、可中断的跨库迁移。
Navicat 的「数据传输」功能不能实现真正的跨库热备份——它本质是同步快照，不是持续复制，也不具备事务一致性保障。如果你需要的是像 MySQL 主从、PostgreSQL 逻辑复制那样的实时/准实时备份，必须换用数据库原生机制；Navicat 数据传输只适合低频、可控、可中断的“冷快照式迁移”。
为什么数据传输 ≠ 热备份
「热备份」要求源库在备份过程中持续提供服务，且目标库能反映备份起始时刻的完整一致状态（即一致性点）。而 Navicat 的 数据传输 功能：
- 不加全局读锁，但对每张表单独
SELECT+INSERT，中间可能写入新数据，导致目标库状态是“拼凑出来”的，非某一时点快照 - 不支持
--single-transaction这类 InnoDB 一致性参数，无法规避长事务干扰 - 传输过程无断点续传，网络抖动或超时就失败，重试需全量重来
- 不记录 binlog position 或 LSN，无法用于后续增量追平
哪些场景下可以用数据传输“假装热备”
仅当满足全部以下条件时，才可把 数据传输 当作轻量级准实时同步手段：
- 源库为 InnoDB，且业务写入压力极低（QPS
- 目标库允许短暂延迟（分钟级），且你接受“最后几秒数据丢失”
- 已手动在源库执行
FLUSH TABLES WITH READ LOCK（仅限短时、低峰期），再启动传输（此时才是近似一致） - 传输完成后立即在目标库运行
CHECKSUM TABLE对关键表校验，而非只看 Navicat 的“成功”提示
实际操作中必须改掉的默认设置
Navicat 数据传输界面默认配置会放大不一致风险：
- 禁用「插入前清空目标表」：勾选它会导致目标库在传输中途空窗，业务查不到数据；应改用「跳过已存在记录」或「更新冲突记录」，并确保主键/唯一键定义严格一致
- 关闭「自动创建目标表」：否则字段类型可能被弱转换（如
VARCHAR(255)变成TEXT），后续INSERT ON DUPLICATE KEY UPDATE失效 - 显式指定字符集：在「高级」选项里填
--default-character-set=utf8mb4，否则中文字段可能存成问号（尤其从旧 MySQL 5.6 迁出时） - 限制并发线程数：设为
1或2，避免多表并发 SELECT 把源库内存打满，触发 OOM Kill
真正该盯住的三个失败信号
数据传输界面显示“完成”，不代表数据可靠。务必检查：
- 日志窗口末尾是否出现
Warning: Data truncated for column 'xxx'—— 字段长度不匹配，静默丢数据 - 目标库中
information_schema.TABLES显示的TABLE_ROWS是否与源库基本一致（允许 ±0.1%，因统计非精确） - 用
SELECT COUNT(*)对比几张核心大表行数，别信 Navicat 自带的“传输了 XXX 行”计数（它只算 INSERT 成功数，不含跳过的重复行）
跨库传输最易被忽略的，是源库和目标库的 sql_mode 差异。比如源库开着 STRICT_TRANS_TABLES，目标库没开，某些隐式转换就会让数据“看起来一样，实际不同”。每次传输前，先跑一遍 SELECT @@sql_mode 对比两边。这不是细节，是数据一致性的底线。
