Navicat数据同步无预览执行后无法回滚，因操作非事务性且独立分批执行；补救需立即停写、查生成脚本、比对源目标数据，或反向同步恢复，关键在同步前强制预览、备份和映射核验。
数据同步没点“预览”就执行，怎么补救
Navicat 17 的「数据同步」本身不提供执行后一键回退的按钮。它不是事务性操作，一旦点击 开始同步 并完成，目标库的数据就已写入，ROLLBACK 在这里完全无效——因为同步过程是独立连接、分批 INSERT/UPDATE/DELETE，不跑在你当前会话的事务里。
所以关键不是“怎么撤销”，而是“怎么把损失控制在最小、恢复速度最快”。下面几步是实操中真正能用上的路径：
- 立刻停止所有对目标库的写入操作，避免二次覆盖
- 检查同步向导最后一页是否勾选了
生成同步脚本：如果勾了，打开生成的.sql文件，里面明确写了哪些表被改、哪些行被删，可针对性修复 - 确认源库和目标库是否仍保持连接：用 Navicat 分别连上两者，右键目标表 →
选择行，再右键源表 →选择行，手动比对几条关键记录（比如主键范围、时间戳最新几条） - 若同步前没备份目标库，但源库数据完整，可直接再次发起反向同步（源←目标设为新源，原目标←设为新目标），但必须先清空目标库对应表或加
WHERE条件限制范围
为什么“同步前预览”比“同步后补救”重要十倍
很多人跳过 预览 步骤，是因为觉得“只是同步几张表，能出什么问题”。但真实翻车场景往往卡在细节：
-
字段映射错位：比如源表的updated_at被映射到目标表的created_at，时间全乱 -
空值处理不一致：源字段允许 NULL，目标字段设了NOT NULL DEFAULT ''，同步时自动填充空字符串，原始 NULL 语义丢失 -
主键冲突策略选错：选了更新匹配行，但源数据里有重复主键，结果只保留最后一条，中间数据静默消失 -
字符集未显式指定：源库是utf8mb4，目标库是latin1，中文变问号，且不可逆
这些在 预览 窗口里都以红字或感叹号标出，但一旦跳过，就只能靠人工核对。
用“结构同步”误当“数据同步”，结果更难收场
新手常混淆 结构同步 和 数据同步：前者改的是表定义（字段、索引、约束），后者改的是表里的实际行。如果你本想同步数据，却手滑点了 结构同步，还点了 执行，那可能已经删了目标表、重建了新结构——此时数据不仅没同步，连原有数据的存储格式都可能不兼容了。
这种情况没有快捷路。必须：
- 立刻从备份中恢复目标库的旧表结构（注意：不是数据，是
CREATE TABLE语句） - 用 Navicat 的
数据传输功能，把源库表数据导出为INSERT语句，再导入到刚恢复结构的目标表 - 跳过自增主键冲突：导出时勾选
忽略 AUTO_INCREMENT 值，否则可能报错Duplicate entry for key 'PRIMARY'
真正防翻车的三个动作，每次同步前必须做
不是功能越强越安全，而是习惯越细越省事。以下三步花不到 20 秒，但能避开 90% 的同步事故：
- 右键目标连接 →
备份数据库，哪怕只备份单张表，选快速备份模式，5 秒完成 - 在同步向导第 3 步（字段映射页），鼠标悬停在任意映射关系上，确认弹出的提示里写的是
source.column_name → target.column_name，而不是反的 - 点击
预览后，拉到最底部看 Summary 区域的三行数字：Insert: X rows、Update: Y rows、Delete: Z rows——如果Delete不为 0，立刻停下，检查 WHERE 条件或匹配逻辑
同步操作的复杂点从来不在按钮多难点，而在于它把多个独立数据库操作打包成一个黑盒流程。你看到的“一步同步”，背后可能是几十次独立连接、上百条 SQL 执行。一旦出错，没有统一事务兜底，只能靠前置判断和快速定位。
