信创迁移这套事，走到切换节点时，最让人发怵的往往不是架构改造有多复杂，也不是性能调优还留了多少尾巴，而是会议室里所有人都在等你拍板：“能不能切？”真正让你下不了决心的，通常不是对上线流程不熟，而是对“数据一致性校验”心里没底。如果没有一套足够硬的校验方案，“不敢切”这三个字就永远是最后一公里的常态。
数据一致性校验，听着像个纯技术问题，但骨子里是个风险管理问题。切换窗口有限，业务停顿时间以分钟计，你不可能把几百张表全部重新导一遍，也不可能在冻结窗口里跑一套耗时数小时的全量校验。你需要回答的是：在有限时间和有限资源内，用什么样的检查组合，才能把“数据不一致”的风险压到业务可接受的范围。这篇文章就围绕信创迁移场景，把一致性校验的方案思路、实操细节和坑点完整捋一遍。
1. 先搞清楚“一致性”到底要证明什么
1.1 一致性不是“一模一样”，而是“业务可接受”
很多团队对一致性校验的理解，就是“两张表行数一样就算一致”。这个认知在迁移项目里非常危险。行数一致只能说明数量对得上，完全不能证明值对得上。举个例子，某账户余额字段，源端是100元，目标端是99.99元，表里都只有一条记录，行数、主键集合全部一致，但业务一跑就出问题。这种差异是致命的，而它恰恰能绕过最粗糙的校验手段。
所以做校验之前，先要把一致性的层次拆出来：
- 结构一致：表结构、字段、索引、约束、视图、存储过程、序列等数据库对象一致。
- 集合一致：主键集合相同，没有源端多、目标端少或目标端多、源端少的情况。
- 值一致：每条记录对应的业务字段一致，包括类型转换后的精度、格式、时区表现。
- 时序一致：增量同步过程中，数据在时间窗口内保持一致，不出现漏同步或错顺序。
这四个层次不是并列关系，而是层层递进。结构不对会导致后面的数据根本没地方放；集合不对意味着有缺行或多行；只有集合对了才开始谈字段值对不对。很多迁移方案只做到集合一致，就敢宣布“数据没问题”，这是把一致性校验做成了碰运气。
1.2 校验动作不能是“一次性验收”，而应是“全周期证据链”
项目里还有一种常见做法：临切换前，让开发在两套库分别跑一遍select count(*)，没报差异，于是宣布“数据一致，可以切”。这种做法最大的问题在于，它不覆盖字段级差异，也不覆盖数据漂移。你在T1时刻跑完count，T2时刻源端可能又写入了一笔业务数据，如果增量链路没有把这一笔送过去，到T3时刻切换时，两个库其实已经不一致了，而你手里还握着一份“count一致”的旧报告。
一致性校验应该贯穿迁移的三个阶段：迁移前的基线校验、停写窗口的冻结比对、切换后的事后复核。每一阶段输出的报告，都要能回答“什么时间、对哪些表、用什么方法、发现了什么差异、如何处置”。这套完整的证据链，才是你拍板“可以切”的依据，而不是某一次孤立的查询结果。
| 校验阶段 | 主要目标 | 典型动作 | 输出物 |
|---|---|---|---|
| 迁移前基线 | 确认全量数据迁移正确 | 结构比对、全量行数、分片哈希、关键字段抽查 | 基线校验报告 |
| 切换冻结窗口 | 确认增量追平后无差异 | 停写、追平位点、冻结比对、差异熔断 | 切换校验报告 |
| 切换后复核 | 确认新库承接业务正常 | 全量关键表复核、抽样、对账、持续监控 | 复核报告与告警记录 |
2. 迁移前的基线校验：切换没开始，校验已经要跑起来了
2.1 先定基线版本，让源端和目标端在同一个时间点上比对
信创迁移大多数不是停机导数据，而是“全量+增量”的持续同步。这时如果没有一个明确的基线时间点，后续所有校验都会说不清差异来源。
所谓基线，就是给源端存量数据画一条时间线。比如确定T0为迁移启动时间，T0之前的数据作为全量范围，T0之后产生的数据作为增量范围。全量导入完成后，先针对T0之前的存量数据做完整校验；然后开启增量同步，定期对T0之后的新增数据做增量校验。等到增量追平、切换窗口打开时，再做一次统一冻结比对。
实际操作中，如果业务表里有统一的修改时间字段，可以用时间点切分存量与增量；如果表没有时间字段，就只能以抽取时刻为准，同时记录抽取对应的日志位点或快照编号。这个位点是后续判断增量是否追平的关键依据，一定要记录清楚并写进校验报告。
2.2 结构一致性校验：不止是对表结构，还有序列和索引
结构一致性是数据一致性校验的地基。地基如果歪了，后面比对出来的差异再多，也很难分清楚是数据问题还是结构问题。需要比对的几类对象包括：
- 表本身：表名、字段名、字段类型、默认值、自增属性、字符集排序规则。
- 索引与约束：主键、唯一索引、普通索引、外键约束、检查约束。注意索引名相同但列顺序不同也算结构差异，会影响查询计划。
- 序列与自增器：当前值、步长、最大值、是否循环。序列不同步会导致新库插主键冲突，这类问题不提前查出来，切换当天必然炸。
- 视图、存储过程、函数、包：定义文本做全文对比，很多迁移工具对这类对象支持不足，需要手工导出后diff。
- 分区定义：分区表的分区类型、分区边界、分区数量要一致，否则后续数据分布和访问路径都会变。
结构比对建议做成自动化任务，所有对象定义导成文本文件，用文本差异工具跑一遍。脚本在迁移前就要写好，不要等到切换当天才手工操作。切换期间人的精力应该放在处理异常上，而不是写比对脚本。
2.3 数据集合一致性校验：行数加主键分片，缺一不可
行数一致只是最基础的要求，还应该做主键集合比对。所谓主键集合比对，就是对比源端主键集合与目标端主键集合的差集。主键集合完全一致，才能说明没有丢行和多余行。
但一个大表几千万行，直接把两个主键集合拉到内存里做差集是非常愚蠢的。正确做法是分片：
-- 以用户表为例，按主键ID取模分片 SELECT MOD(ABS(id), 10) AS shard_id, COUNT(*) AS row_cnt, MIN(id) AS min_pk, MAX(id) AS max_pk FROM source_user_account GROUP BY MOD(ABS(id), 10) ORDER BY shard_id;源端和目标端分别执行同样逻辑的分片查询，然后对比每个分片的行数、最小主键、最大主键。哪个分片对不上，就把范围缩小到哪个分片，再对这个分片做行级哈希比对。这样既能缩短比对时间，又能快速定位差异范围。
分片数怎么定？可以先拿全量行数除以预期的单分片行数，比如单分片控制在50万到100万行，太大则定位粒度太粗，太小则分片请求过多压垮源库。我一般建议并行度控制在4到8个，分片数在16到32之间，既不会拖慢迁移进度，也不会把数据库连接池打满。
2.4 字段级一致性校验：全表哈希、分片哈希和按行哈希怎么选
主键集合一致之后，下一步就是对记录内容做校验。这里常见三种方案：
全表哈希，将整张表所有行的所有字段拼接后计算哈希值，速度快，但无法定位差异行，而且对CLOB、BLOB等大字段非常不友好。
按行哈希，对每行数据单独计算哈希，再汇总比对，能精确定位差异行，但计算开销大。几百万行的表，每行哈希一次，耗时可能是全表哈希的几十倍。
分片哈希是折中方案，先按主键分片，对每个分片内的所有行拼接后的内容计算一个哈希。哪个分片不一致，再下钻到这个分片的行级哈希去找具体记录。这个方案兼顾速度和定位精度，最适合切换窗口比较紧张的场景。
大字段处理有个经验：CLOB、BLOB、JSON这类字段不要放在第一轮哈希里。第一轮先把普通字段全部比对完，大字段单独抽检。抽检时可以用数据库自带的哈希函数，比如Oracle的DBMS_SQLHASH.GETHASH，或把大字段截取前N个字节做摘要对比，全部字段做二进制全比对的成本太高，通常不划算。如果业务对大字段完整性要求非常高，再单独抽核心表做全量二进制比对。
另外，数值类型哈希之前必须统一格式化。源端NUMBER(10,2)存的是100.00，目标端DECIMAL(10,2)显示为100，如果直接拼接字符串，肉眼看到的是相同数值，但哈希值对不上。这类“伪差异”会消耗大量排查时间，最好在拼接字段前统一转换格式。
2.5 业务规则校验：数据库比对之外必须补的功课
字段级比对只能证明源和目标在数据库层面的表现一致，不能证明业务语义一致。比如订单表所有字段都一样，但订单金额汇总对不上总账，那说明问题可能出在同步链路之外的业务逻辑上。所以迁移方案里要有一组业务规则校验，通常包括：
- 汇总一致性：源端订单总金额与目标端订单总金额一致，且与支付流水汇总一致。
- 状态机检查：业务状态字段只能出现在合法的转移路径中，目标端不能出现源端不存在的状态组合。
- 外键关联性：明细表记录必须能在主表找到对应记录，不能出现孤儿数据。
- 余额轧差：用户账户余额等于交易流水汇总加初始余额，源端和目标端都满足这个等式。
业务规则校验不用覆盖全部表，只覆盖核心业务表和关联复杂度高的表。把这些规则做成一个“校验清单”，在迁移前至少跑三轮：全量导入完成后一轮，增量追平后一轮，冻结窗口的比对前再来一轮。三轮都通过，切换的底气才足。
3. 停写窗口里的实时校验：切换瞬间的“冻结比对”怎么做
3.1 先看同步链路，再对数据
停写窗口里的校验，第一步不是跑SQL，而是看同步任务的健康状态。大量不一致并不是“迁移工具导错了”，而是增量链路漏了：DDL没有同步，目标端建好的表源端同步任务根本没识别；触发器或物化视图让目标端多出一批源端没有的数据；序列没有迁移，目标端插入主键冲突后同步任务反复重试又丢失事务。
所以冻结比对之前，必须确认三件事：
- 增量同步任务处于“已追平”状态，也就是同步位点已经推进到源端最后一个事务。
- 同步任务没有错误队列堆积，没有被过滤掉的记录。
- 同步过程中是否出现DDL跳过、主键冲突、类型转换失败等告警，如果有，先处理干净再进入比对。
同步链路的健康状态，要像看体温一样每天盯。曾经有个项目，增量任务白天跑得好好的，每天晚上定时清理日志的任务会触发一次DDL，同步工具不支持这种类型的语句，直接跳过了。表面看数据一切正常，实际上两张关联表的约束关系已经悄悄变了。要不是切换前检查了同步告警日志，这个问题上线后极难发现。
3.2 停写冻结窗口的操作清单
切换窗口建议按以下顺序执行，每一步都有人确认、有记录：
- 启动业务变更冻结，应用侧停止所有写操作。
- 等待增量同步追上源端最后一个事务，记录同步位点。
- 在源端和目标端分别写入一条校验标记记录，确认两边的标记一致。
- 对核心业务表执行分片级集合比对和字段级抽查。
- 比对无差异后，切换读流量到目标库。
- 开启目标端写流量，同时启动反向保护。
这里很容易忽略的是“等待所有活动事务结束”。增量同步追到位点，不代表所有老事务都已经提交完。要确认源端没有正在运行的长事务，否则你抽到的数据可能是事务提交前的旧版本。比如一个对账程序在切换前跑了一个多小时的大查询，切换窗口打开时它还没结束，那你比对的源端数据实际上是几分钟前的快照，和目标端最新数据天然存在差异。
3.3 核心表分类：不同数据量级的表用不同力度校验
停写窗口通常只有几分钟到十几分钟，不可能每张表都做全量行级比对。建议把表分为A、B、C三类：
- A类，资金、订单、用户、权限等强核心表。这类表必须做全量行级校验，不能抽样。
- B类，业务扩展表、配置表、中间表。可以用分片哈希比对。
- C类，日志、流水、归档类大表。只做行数、时间水位、抽样字段校验，换取时间。
分类不是看表有多大，而是看表影响什么业务。A类表再大也要全量校验，C类表再大也只做粗粒度校验。资金差错一分钟都不能忍，但访问日志少了两行，往往不影响主流程。
3.4 一个可复用的“冻结比对”脚本思路
在切换窗口里，我会用一套极简比对脚本：按分片从源端和目标端分别取数，在内存中做归并比较，输出source_only、target_only、diff_values三类差异。以下是简化逻辑：
def compare_shard(table_name, pk_column, shard_expr, src_conn, tgt_conn): src_rows = load_rows(src_conn, table_name, shard_expr) tgt_rows = load_rows(tgt_conn, table_name, shard_expr) src_map = {row[pk_column]: row for row in src_rows} tgt_map = {row[pk_column]: row for row in tgt_rows} for pk in src_map.keys() - tgt_map.keys(): emit_diff("source_only", table_name, pk) for pk in tgt_map.keys() - src_map.keys(): emit_diff("target_only", table_name, pk) for pk in src_map.keys() & tgt_map.keys(): if src_map[pk] != tgt_map[pk]: emit_diff("value_diff", table_name, pk)这段代码是最直白的形态，实际项目中要加线程池、分片参数、字段过滤规则和差异阈值熔断。比如差异条数超过100条就停止当前表比对，先出报告再说，不要等到把所有差异都翻出来才报错，那样只会让切换窗口白白流失。
脚本的另一个关键点是，源端和目标端从同一个配置表读取比对对象和比对字段，不要在代码里写死。这样新增表时只要在配置表里插一条记录，不需要改代码重新发布。
3.5 如何避免比对过程拖垮数据库
冻结窗口里，数据库非常敏感。如果你在切换前用大查询去扫全表，很容易触发目标库的慢查询堆积，或者把源库的日志、锁、内存都吃满。几个经验：
- 优先在备库或只读实例上执行校验查询，不要在正在承接流量的主库上跑。
- 设置事务隔离级别为只读快照，避免长事务锁住正在变更的数据。
- 大表按主键范围分段，每段单独查询，控制每次扫描的数据量。
- 限制校验连接数，并行度4到8就够，不要开几十个线程去怼同一个库。
- 给校验任务设置执行时限，比如每个分片查询超过30秒就直接标记为失败并人工介入。
切换窗口期间，校验任务和业务流量并存。宁可校验慢一点，也不要把库压垮。校验慢顶多晚几分钟出结论，库被压垮可能整个切换窗口就废了。
4. 切换后的事后复核与持续观察：切换只是校验的开始
4.1 首日双重复核：强校验加业务对账
切完之后，很多人会松一口气，觉得数据既然切过去了，就万事大吉。实际上切换后第一周才是数据一致性风险最高的时候。停写窗口的校验只是瞬时验证，业务在目标库跑起来之后，新写入的数据、定时任务、外部接口都在持续改变库内状态，任何一条隐藏的转换规则漏洞都会被放大。
首日复核建议做双重的：
第一重是全量强校验。如果源端已经停写，那么目标端和源端都是静态库，直接对核心表做全量行级比对，不留抽样。如果源端还处于只读状态，同样可以做到全量比对。只有源端完全释放，或者已经被初始化，才退而求其次做抽样。
第二重是业务对账。数据库比对只能证明表一致，业务对账能证明计算链路正确。比如订单表金额汇总与支付表金额汇总是否平账，用户余额与交易明细轧差是否相等。这类对账任务要定时跑，每天凌晨低峰期执行，生成对账报表。对账不平，哪怕表字段全部一致，也不能放过。
4.2 抽样比例怎么定：不能拍脑袋，要分表分级
切换后如果没有条件做全量校验，就需要抽样。抽样比例不是“每个表抽10%”这种一刀切，而是根据表的风险等级和数据特征来定：
- 核心资金类表：100%全量校验。
- 主数据类表，如用户、机构、产品：建议100%校验，因为有关系型下游。
- 事务类大表，如订单流水、交易明细：至少抽30%，且样本要按主键分片均匀抽取。
- 日志类表：抽5%即可，重点看时间水位、编号连续性、字段格式。
抽样方法也要讲究。不能只抽前N条，要分层抽样。比如按主键取模，每100条里抽5条；或者按日期分层，每天随机抽若干条。这样才能覆盖不同时间段的数据特征，避免只验了某一个分区的数据。
4.3 持续监控的阈值与告警：宁可错杀，不可放过
切换后不能只靠人工去查，要有自动化的差异监控。校验任务每天凌晨跑完之后，自动判断是否触发告警。参考阈值如下：
| 监控指标 | 阈值 | 动作 |
|---|---|---|
| 核心表差异记录数 | 0 | 大于0立即阻断次日业务变更 |
| 非核心表差异记录数 | 10 | 超过则告警，进入排查 |
| 字段差异率 | 0.01% | 超过则告警并调大抽样比例 |
| 对账差额 | 0.01元 | 超过则生成对账异常单 |
| 增量同步延迟 | 60秒观察，300秒告警 | 延迟期间暂停下游依赖任务 |
| 校验任务执行失败次数 | 连续2次 | 人工介入，停止自动判断机制 |
这些阈值不是拍脑袋定的，它们对应的是业务容忍度。资金差一分钱都不能忍，非核心配置表差几条可以等上班后处理。阈值定义清楚后，要写进校验配置，让系统自动执行，不要依赖某个人每天早上肉眼看一遍报表。
我在某项目里见过一个让人后背发凉的场景：切换后第二天的自动校验报告显示核心表差异数为零，但第三天业务对账不平。后来排查发现，校验任务在比对时漏掉了两个被业务忽略的字段，而这两个字段恰好是下游对账的关键键值。从那以后我养成了一个习惯：校验工具的字段配置必须由业务方和技术方共同确认一轮，而不是DBA自己勾选。
5. 回切方案：校验不是单向的，要能“回得去”
5.1 为什么必须把回切纳入校验设计
切换失败要回退，这是每个迁移方案的白纸黑字约定。但回退选项如果只是写“执行回切脚本”，而不做回切场景的数据校验，那这个回切方案就是一张空头支票。
回切和正向迁移不是简单的反向操作。正向迁移时，源库是可信数据源，目标库是待校验的影子。回切时，目标库已经承接业务跑了一两天，里面不仅有迁移过来的存量数据，还有新产生的增量数据。此时如果直接回切到源库，源库里缺少这些增量数据，会造成业务损失。
所以，回切方案里必须明确几个问题：源库从切换后开始就保持只读，还是继续接收同步？目标库产生的增量数据如何回流到源库？回流过程用什么机制避免两端数据互相覆盖？这些问题不提前设计，切换当天遇到失败只能两眼一抹黑。
5.2 回切前要做的反向校验
如果目标库作为新主库运行期间，源库一直通过反向同步任务接收增量数据，那么回切前的校验重点包括：
- 反向同步的延迟是否在可接受范围，延迟过大会导致回切丢失数据。
- 反向同步是否出现重复写入，特别是源库本来自增主键，反向task再次插入同主键记录时是否冲突。
- 目标端的删除操作是否同步到了源端，很多反向同步工具默认不做删除同步，这是大坑。
- 序列是否还在正常推进，如果目标端和源端各自生成序列，回切后再次切换会导致主键空间重叠。
回切前的校验动作，可以复用正向迁移的脚本，只要把源端和目标端在配置表里互换一下即可。但要注意，反向校验时目标端的数据仍在变更，所以比对必须做在冻结窗口里，不能边写边比。
5.3 回切演练要专门为校验留预算
回切演练不能只演练应用启动和路由切换，数据校验脚本也要一起演练。我见过的回切预案里，90%只写了“执行回切步骤”，没有约定“回切后多久跑一次全量差异比对”。结果真到演练时，脚本因为数据库连接池配置错误跑都跑不起来，直接把演练变成了一场“真实事故预演”。
建议在演练环境人为制造两类差异，验证校验工具能不能发现。差异类型要包含源端多、目标端少和目标端多、源端少两种情况。如果工具连人为制造的差异都发现不了，那这套校验能力根本不能用于正式回切决策。
6. 常见问题与排查技巧实录
6.1 我见过最多的六类差异原因
| 差异类型 | 常见原因 | 排查思路 |
|---|---|---|
| 源端多行、目标端少行 | 增量同步漏单、任务中断后未追平 | 查同步任务断点、日志位点、按主键分片重新比对 |
| 目标端多行、源端少行 | 导入任务重复执行、触发器造数、手工补录 | 按业务主键查重复记录，检查导入任务是否幂等 |
| 字段值不同 | 类型转换规则错误、时区偏移、字符集乱码、默认值覆盖 | 抽取差异行查看源端原始值，按转换规则逐项验证 |
| 结构不一致 | DDL未同步、索引创建顺序不同、序列未迁移 | 对比元数据快照，重建索引和序列 |
| 行数相同但业务对不上 | 数据错位、更新被覆盖、主键集合碰巧一致 | 做关键字段哈希比对和业务汇总对账 |
| 时区导致日期变化 | 源端无时区概念，目标端自动转换 | 统一会话时区，按UTC存储或显式加偏移量 |
6.2 校验工具说“通过”，但可能正在骗你
市面上有不少迁移比对工具，但“工具通过”不等于“数据一致”。我就踩过这样的坑：某个开源比对工具默认忽略字符串字段的尾部空格，NULL和空串也被认为是等价，结果一个char(10)存“abc”和一个varchar(10)存“abc”被归为一致，工具直接出了“无差异”报告。业务侧对这个字段要求很严格，不允许尾部空格存在，那这条数据其实就是残次品。
所以对工具要保持审慎：
- 逐条过一遍工具的比对参数，搞清楚它默认忽略什么、不比较什么。
- 用一个故意制造差异的样例库先自测工具，样例里要包含空串、NULL、大字段、精度差异这些边界场景。
- 至少保留一种不依赖工具的校验方式，用SQL加脚本做人工复核，作为工具结论的交叉验证。
6.3 校验任务把数据库跑挂的排查史
有一个项目切完两天后，每天凌晨跑自动校验，目标库CPU直接飙升到100%，业务侧开始出现大量超时告警。当时第一反应是业务流量异常，排查了半天才发现是校验脚本引发了风暴。
原因很简单：校验脚本对一张亿级流水表做全表扫描，且没有按主键分片，单条SQL执行了将近四十分钟。更麻烦的是脚本一次性开了16个并行连接，每个连接都在扫不同的表，全部命中资源竞争。后来调整成按天分区扫描，每天只校验当天的数据分区，并行度降到4，CPU立刻恢复正常。
经验总结：校验任务必须和业务任务错峰执行，必须限制并行度，必须让每条SQL都走索引。
6.4 空字符串、NULL和尾部空格造成的“伪差异”
这种问题最费时间，而且特别容易让人误判。某次校验报告里标了三千多条差异，全是同一个字段。看数据发现，源端值为NULL，目标端值为空字符串，肉眼觉得“这俩应该算一样吧”，但脚本判定它俩不一致。
解决办法是建立一个“等值规则表”，让校验脚本按规则比较：
NULL与空字符串是否等价；- char类型尾部空格是否被裁剪后再比较；
- 时间字段是否按UTC标准比较；
- 小数位是否保留两位后比较。
把这些规则配置化，而不是在代码里写死，这样后续遇到新的伪差异，改配置就能解决，不用改代码再跑一轮。
6.5 大表和无主键表，不能用常规手段硬碰
没有主键的表在比对时缺少稳定的定位锚点，非常难受。处理方法是先找一组业务上能唯一标识行的字段，拼成“逻辑主键”再做分片。找不到唯一字段的，可以临时用ROW_NUMBER开窗生成序号，比对时源端和目标端各自按相同排序规则生成序号，再按序号对齐。但要注意，这种方式只适用于静态比对，一旦源端数据在排序过程中发生变更，对齐就会错位。
大字段的表建议拆开处理。第一轮只比对普通字段，大字段单独抽一条样本做二进制比较。如果发现差异，再扩大到抽样范围。不要一上来就对所有大字段做全量二进制比对，那个时间消耗非常惊人。
6.6 校验结果必须形成可追溯的证据链
切换之后如果业务出了任何问题，校验记录就是第一手的排查线索。迁移项目目录下应该保存这些内容：
- 校验脚本版本和Git提交号。
- 每次校验任务的执行时间、执行角色。
- 每张表的比对SQL和结果摘要。
- 差异清单及处置记录。
- 对账报表。
- 业务复核确认记录。
这套证据链的价值，在顺利切换时看不出来，一旦出了事故，它就是还原现场的唯一依据。审计也好，复盘也好，没有这套记录，你连“当时为什么判定没问题”都说不清楚。
7. “算够”的最终标准：三个问题必须能回答
7.1 校验结果能回答“差异在哪里”
如果校验报告的结论只有“一致”或“不一致”，那这个报告是不合格的。真正合格的报告要能定位到表、分片、记录、字段，并说明差异类型。比如：“用户表分片8，源端比目标端多3条记录，主键分别为1001、1003、1020；另有2条记录余额字段不一致，其中一条源端为100.00，目标端为99.99。”
做到这种粒度，技术团队才能在切换窗口内快速判断问题范围，业务团队才能评估影响。如果只能回答“有差异”，那跟没做校验没什么两样。
7.2 校验结果能回答“对业务影响有多大”
数据差异有轻重缓急。核心表的资金字段差一分钱，可能直接引发资金事故；配置表的备注字段差几个字，可能完全不影响业务。因此校验报告要按业务影响分级：
- P0：核心资金、订单、用户主档案的差异，必须阻断切换。
- P1：非核心业务表的差异，需要整改处置后再决定是否放行。
- P2：日志类、归档类表的差异，可放行并持续跟踪。
技术团队不应该替业务方拍板“影响不大”，而是把这个分级和原始差异清单一起摆到决策者面前。
7.3 校验结果能回答“谁有权决定放行”
一致性校验再完备，也只是提供了技术事实。最终切不切，是业务决策。所以从项目启动那天起，就要建立两层机制：技术团队负责给出“有差异、无差异、风险等级”，业务方和项目负责人负责决定“继续切、回切或延期”。
如果到了切换当天，业务方明知核心表存在P0差异还坚持强切，技术团队必须在报告里保留“不满足放行条件”的书面结论，不能口头提醒一句就算了。这个决定必须有记录，避免事后责任不清。
我的体会是，一致性校验这件事，真正的“够用”不是一个静态指标，比如“行数一致”“哈希一致”这种词，而是一套持续运行的风险决策机制。它要从基线到冻结、再到事后复核和回切演练，形成一条完整证据链。让你敢切的那一瞬间，靠的其实不是“我很有把握”，而是“我知道，如果差异出现，它能被快速定位，影响能被准确评估，决策者有明确依据”。能做到这一层，信创迁移这最后一公里，才算真正走完。
