Navicat Cloud 没有真正的版本历史，仅维护每张表的 Local version 和 Cloud version 两个累加计数器，不保存 SQL、字段级 diff 或时间戳；所谓“回滚”实为单向覆盖，无法还原至中间状态。
navicat 同步本身不维护云端版本历史，所谓“利用云端版本历史回滚”是误解——navicat cloud 的 conflict detection 机制只存当前快照比对结果，不保存每次变更的完整时间线。
Navicat Cloud 有没有真正的版本历史？
没有。它只记录每张表的「Local version」和「Cloud version」两个整数编号，由本地修改次数和云端提交次数分别累加生成。不保存 SQL 内容、不存字段级 diff、不存时间戳序列。点开 Tools → Cloud Sync Status 看到的版本号只是计数器，不是 Git 式 commit hash。
- 你无法按日期筛选“昨天下午三点的 users 表状态”
- 右键
Compare with Cloud拉取的是当前云端最新数据，不是某个历史节点 - 所谓“回滚”，实际是手动选
Use Cloud覆盖本地，或Use Local覆盖云端——二者都是单向覆盖，不是还原到某次中间态
同步时提示 conflict detected，但没法定位哪行改过怎么办？
Navicat Cloud 不做字段级比对，只校验主键/唯一键是否在本地和云端存在且值不同。冲突提示弹窗后，必须靠人工交叉验证：
- 先停掉所有正在编辑该表的 Navicat 实例（包括同事的），避免二次写入干扰
- 打开
Cloud Sync Status，找到带 ⚠️ 的表，记下它的Local version和Cloud version - 连上本地库执行：
SELECT * FROM table_name WHERE id IN (SELECT id FROM table_name INTERSECT SELECT id FROM cloud_table)（需先导出云端数据到临时表） - 更实操的做法：用
Export Wizard把本地当前数据导成 CSV，再把云端数据也导一份，用diff或 Excel 对比主键列+关键业务字段
想真能回滚，得自己建 checkpoint 表
Navicat 不提供断点续传或操作日志，sync_checkpoint 表也不是它内置的——那是用户为容错自己建的辅助表。若需要可追溯的变更流：
- 在源库加触发器，把每次 INSERT/UPDATE/DELETE 记进
audit_log表（含table_name、pk_value、old_data、new_data、created_at） - 同步前先查
SELECT * FROM audit_log WHERE created_at > '2026-04-24 18:00:00'，确认哪些行被改过 - 回滚时不用依赖 Navicat，直接手写
UPDATE table_name SET ... WHERE id = ?恢复旧值 - 注意：Navicat 的 merge 操作不会触发触发器，所以审计日志必须在同步前完成记录
真正容易被忽略的点：Navicat Cloud 的冲突判断基于最后一次成功同步后的变更累积，如果中间有人绕过 Navicat 直连数据库改了数据，那个变更永远不会进入版本计数，但会实实在在导致下一次同步报 conflict —— 你查不到它，只能靠定期校验数据一致性。
