一个运营看板开始把订单提前推进到后续阶段：收货刚完成，页面就显示卸货或检验；订单已经发运，报表却仍把它标成较早的核对阶段。真实业务交易还在继续，状态报表描述的操作边界已经偏离现场。

故障同时涉及读写两端。报表接受了流转表中的全部记录，其中包括没有开始时间的行，以及为未来阶段提前生成的占位记录。另一个业务入口在当前阶段结束时立即创建下一阶段里程碑。两类信号进入同一条排序链后，“取最新一条”无法稳定说明哪项工作已经开始。

最终修复把当前状态改成一项可复核的推导结果：先分类流转证据，再统一历史编码，只在事件缺失时使用有限的业务补偿，同时把里程碑写入移到真实转换位置。所有报表视图都改为消费同一个解析结 …

用于升级演练的数据库从一份有效快照复制而来。复制完成后，来源端又增加了结构和字典变化。测试应用开始验收前，目标库需要补齐这些变化，才能得到可比较的基线。

目标库已有部分升级结果，还保留了一项比来源定义更宽、经过验证的兼容改进。同步范围也明确排除了业务记录。若直接顺序执行一组无条件 ALTER、CREATE 和 INSERT，脚本可能在中途遇到重复对象，下一次执行仍会失败；操作人员一旦选错连接，同一组语句还可能落到错误数据库。

最终脚本把同步描述为期望状态：先核对目标身份，再于写入前分类全部差异，只补缺失项，执行后逐项验收，最后完整运行第二次验证零变化路径。

先明确同步边界

来源对比只做读取，并 …