一次在线迁移进入割接前夜，最让人心里没底的通常不是"同步延迟还剩多少"，而是另一个问题：目标库里的数据，真的和源库对得上吗？
源系统没有停。新订单还在写入，支付状态不断更新，售后流程又在修改旧数据。如果只在全量搬迁结束时比一次行数，那份结果几分钟后就会过期；如果把所有校验都留到停写窗口，割接当晚就只能一边等、一边赌。
金仓异构数据同步软件 Kingbase FlySync（KFS）把同步、校验和差异修复放在同一条迁移链路上。数据在持续变化时也能进行比对，多数问题可以在正式切换之前处理完。
全量搬完后，增量要从同一个位点接上
在线迁移有两条同时推进的线。一条处理存量数据，把已经存在的表和记录搬到 KingbaseES；另一条从确定的日志位点开始追增变化，持续处理搬迁期间产生的 INSERT、UPDATE 和 DELETE。
这个位点必须与全量基线对齐。接早了，目标端可能重放已经在全量数据中的变更；接晚了，中间一段交易就会落下。KFS 在 SQL Server 在线迁移场景中，会从全量备份对应的 eventId 开始增量解析，目的就是把全量基线和后续日志接在同一个位置上。
实施时需要保留三类时间点：全量基线生成时间、KFS 开始解析的日志位点，以及目标端已应用的最新序号。延迟看板反映追平速度，位点则说明从哪里开始、已经处理到哪里。两组信息一起看，才能确定增量链路是完整的。
业务还在写，校验不能只数行数
源库仍在承载业务时，两端各执行一次 COUNT(*) 很容易得到不同结果。第一条查询和第二条查询本来就不在同一时刻，这种差异未必是数据丢失。
KFS 的数据比对分为精简模式和详细模式。精简模式用于快速比对源端和目标端的数据量；详细模式可继续定位表内差异，并支持差异校验和无缝校验。其中无缝校验就是给持续有业务写入的场景准备的，避免把正常的并发变更误判为同步异常。校验配置、任务调度、结果查看和大表分片等内容，可以在公开的 KFS 数据校验手册中查到。
我会先用精简模式扫全库，快速找出数量不一致的表，再对订单、支付、退款等核心表启用详细比对。这样不用一开始就对全库所有表做最细粒度校验，也不会把一张小码表和交易主表放在同一优先级上。
工具找差异，SQL 负责核对业务口径
行数对上之后，核心表还要看金额、状态和时间范围。一张订单表即使两端都是 100 万行，也可能存在一条订单缺失、另一条重复的情况。工具给出表级和行级差异，业务验收则用固定口径再核一遍。
例如，按自然日核对订单时，不用对时间列做字符串转换，直接使用左闭右开的时间区间：
sql
SELECT order_status,
COUNT(*) AS order_count,
SUM(order_amount) AS amount_sum,
MIN(updated_at) AS first_updated_at,
MAX(updated_at) AS last_updated_at
FROM biz_order
WHERE created_at >= TIMESTAMP '2026-08-31 00:00:00'
AND created_at < TIMESTAMP '2026-09-01 00:00:00'
GROUP BY order_status
ORDER BY order_status;支付表再单独核对成功金额和订单数，可以及时发现订单状态已经更新、支付流水却还没有到达目标端的情况：
sql
SELECT COUNT(DISTINCT order_id) AS paid_order_count,
COUNT(*) AS payment_count,
SUM(pay_amount) AS paid_amount,
MAX(paid_at) AS latest_paid_at
FROM biz_payment
WHERE pay_status = 'SUCCESS'
AND paid_at >= TIMESTAMP '2026-08-31 00:00:00'
AND paid_at < TIMESTAMP '2026-09-01 00:00:00';这两组 SQL 应在两端使用相同时间窗口和状态口径执行，异构源库的时间字面量语法按原数据库调整。总行数、分组行数、金额合计和最新业务时间同时对上，比单独记录一个 COUNT(*) 更能说明问题。
汇总一致之后，还要排除"少一条又多一条，刚好把总数抵消"的情况。订单号是业务唯一键时，可以先查重复值：
sql
SELECT order_no,
COUNT(*) AS duplicate_count
FROM biz_order
GROUP BY order_no
HAVING COUNT(*) > 1
ORDER BY duplicate_count DESC,
order_no;订单主表与支付表还要检查引用关系。下面这条 SQL 用来找已经到达支付表、但在订单表中没有对应主记录的流水：
css
SELECT p.payment_id,
p.order_id,
p.pay_amount,
p.paid_at
FROM biz_payment AS p
LEFT JOIN biz_order AS o
ON o.order_id = p.order_id
WHERE o.order_id IS NULL
ORDER BY p.paid_at,
p.payment_id;如果日汇总出现差异，不必立刻扫描整天明细。先按小时和状态重新汇总，通常能较快锁定问题发生的时间段：
sql
SELECT date_trunc('hour', created_at) AS hour_bucket,
order_status,
COUNT(*) AS order_count,
SUM(order_amount) AS amount_sum
FROM biz_order
WHERE created_at >= TIMESTAMP '2026-08-31 00:00:00'
AND created_at < TIMESTAMP '2026-09-01 00:00:00'
GROUP BY date_trunc('hour', created_at),
order_status
ORDER BY hour_bucket,
order_status;需要核到具体主键时，可以把两端同一时间窗内的订单主键分别导入受控核验库，再做双向差集。这样不假设两套异构数据库可以直接跨库关联，也不用为了校验而临时打通生产库账号：
sql
-- 源端存在、目标端缺失
SELECT order_id
FROM verify_source_order_key
EXCEPT
SELECT order_id
FROM verify_target_order_key;
-- 目标端存在、源端缺失
SELECT order_id
FROM verify_target_order_key
EXCEPT
SELECT order_id
FROM verify_source_order_key;这四类检查分别覆盖重复、关联完整性、差异时间段和具体缺失主键。它们不替代 KFS 的详细校验，而是把工具发现的技术差异落实到订单、支付和金额这些业务验收口径上。
差异应该在割接前消化
KFS 的详细校验结果会按表展开。存在差异的表可以继续查看到具体数据，选中需要处理的记录后，可将差异同步到目标端。这个流程把"发现不一致"和"处理不一致"连在了一起，不用先导出一份差异清单，再临时编写修补脚本。
核心交易表的修复仍应该纳入变更记录：先确认源端是正确方向，再执行差异同步，完成后重跑详细校验和业务 SQL。对账结果、修复时间、影响表和处理人留在同一份割接记录里，正式切换时就不会重新翻聊天记录找结论。
低侵入的前提，是把重活移出源库
KFS 基于数据库日志捕获增量变更，不需要在每张业务表上挂一套同步触发器。解析、传输、目标端应用和校验由独立的同步链路承担，源库继续处理原有交易。电科金仓给出的典型场景口径是，校验期间源端 CPU 负载增幅控制在 3% 以内。这个数字用于说明产品在典型场景下的资源影响，正式实施仍需按本地数据量、业务负载和校验并发度压测确认。
正式项目中，这个指标会与同步延迟、日志产生速率、网络带宽和目标端应用速度一起纳入监控。先让小表和核心表分组运行，再逐步增加校验并发度，既能保持效率，也能看清当前资源余量。
"0 数据丢失"要落到割接清单上
在线迁移把原来集中在停机窗口内的工作前移了：存量数据提前搬，增量日志持续追，差异边校验边修复。进入最后切换窗口后，仍要按既定割接方案控制源端写入，确认同步服务在线、增量已追平、核心表详细校验通过，然后完成应用连接切换和业务回归。
这套方法已经用在通信行业。公开的海南移动故障管理系统双中心案例中，KFS 通过增量日志同步、数据过滤和全周期实时一致性校验支撑同城双中心，案例披露的最大同步延迟为亚秒级。它说明日志同步与持续校验可以放在同一套生产链路中，具体项目则要以自己的数据规模、网络和负载验证结果为准。
到了割接指令真正下发的时候，"0 数据丢失"不再是口头上的保证。日志位点、同步延迟、详细校验结果、差异修复记录和业务对账 SQL 都已经准备好。运维人员要做的，是按清单逐项确认，然后把流量交给 KingbaseES。