在MySQL数据归档实践中，源表与归档表分处不同实例或不同库时，网络抖动、批量中断、重复执行都会让两端数据悄然失配。要保证归档可靠，必须在迁移完成后做系统性一致性校验，而不是仅凭行数相等就认为安全。一致性校验的本质，是以可控成本确认源端已归档数据与归档端接收数据在逻辑上完全等价。
一致性校验应覆盖哪些维度
很多团队做归档校验只比对SELECT COUNT(*)的结果，这其实非常危险。行数一致仅能说明总量可能没丢，但无法发现某行被重复插入、某列内容被截断、或者时间区间错位等问题。真正严谨的校验至少要包含四个维度：行数、主键或唯一键集合、关键字段的聚合摘要、业务连续性边界。
主键集合比对能发现缺失或多余记录。比如源表主键为id，可以分别查出两端id列表做差集。关键字段摘要通常指对金额、状态等字段做SUM或MD5聚合，避免逐行拉取全部内容。业务连续性边界是指归档通常按时间切分，需要确认源表create_time < '2023-01-01'的数据是否全部进归档，且归档中不存在该时间之后的脏数据。
字符集与排序规则也会影响摘要比对。如果源库用utf8mb4_general_ci而归档库用utf8mb4_unicode_ci，同样的字符串在函数摘要中可能不同。因此在设计校验前，先统一两端表结构定义，尤其是COLLATE属性，否则会出现伪不一致。
基于_checksum的轻量校验方案
MySQL自带pt-table-checksum类的思路也可在归档场景简化使用。核心是对源表和归档表按块计算聚合值，再比较每块摘要。下面示例用存储过程思维在应用层实现分块MD5摘要，避免全表扫锁。
我们在源库执行按主键分片的校验查询，每片一万行，计算该片的id拼接串与amount总和。归档库用同样分片逻辑计算，两端比对即可。若某片不一致，再下沉到行级核查。这种方式把不一致定位成本从全表降到分片，非常适合亿级表归档。
-- 源库分片摘要（按id范围） SELECT FLOOR(id / 10000) AS chunk_no, COUNT(*) AS row_cnt, SUM(amount) AS sum_amt, MD5(GROUP_CONCAT(id ORDER BY id)) AS id_sign FROM source_order WHERE id BETWEEN 1 AND 1000000 GROUP BY FLOOR(id / 10000); -- 归档库同样逻辑 SELECT FLOOR(id / 10000) AS chunk_no, COUNT(*) AS row_cnt, SUM(amount) AS sum_amt, MD5(GROUP_CONCAT(id ORDER BY id)) AS id_sign FROM archive_order WHERE id BETWEEN 1 AND 1000000 GROUP BY FLOOR(id / 10000);
上述方式优点是计算在数据库内完成，网络只传摘要。缺点是对GROUP_CONCAT有长度限制，需在会话设group_concat_max_len。另外如果归档表做了分区，应让分片键与分区键对齐，防止跨区扫描拖慢实例。
自研逐行比对与自动化校验脚本
当数据量中等或需要精确知道哪行不一致时，可以写脚本拉取双端主键，在内存做集合比对。下面Python示例展示如何用生成器避免内存爆掉，同时利用游标流式获取。
脚本先查源表id集合，再查归档表id集合，求差集得到缺失与多余。随后对交集部分若摘要异常，再按批拉取整行做字段级diff。这种方案灵活，能兼容源端有逻辑删除、归档端做了扁平化转换等复杂映射。
import pymysql
src = pymysql.connect(host='127.0.0.1', user='u1', password='p1', db='src_db')
arc = pymysql.connect(host='192.168.0.1', user='u2', password='p2', db='arc_db')
def fetch_ids(conn, tbl):
cur = conn.cursor()
cur.execute(f"SELECT id FROM {tbl} ORDER BY id")
while True:
rows = cur.fetchmany(10000)
if not rows:
break
for r in rows:
yield r[0]
src_ids = set(fetch_ids(src, 'source_order'))
arc_ids = set(fetch_ids(arc, 'archive_order'))
missing = src_ids - arc_ids
extra = arc_ids - src_ids
print("missing:", len(missing), "extra:", len(extra))
自动化层面，建议把校验作为归档任务的后置步骤，校验不通过则告警并阻断后续清理。同时保留每次校验的摘要快照，方便回溯某次归档是否引入偏差。对于超大规模，可把校验拆成多个定时子任务，利用低峰期跑，避免影响线上。
常见陷阱与规避办法
第一个陷阱是逻辑删除未同步。源表用deleted=1标记删除，归档时若只导deleted=0，校验时源端按全量算就会不一致。应在校验逻辑中显式排除已删除行，或归档时携带删除标记。
第二个陷阱是时间字段时区。源库create_time存UTC，归档库误存本地时区，导致边界比对错位。统一在校验SQL中用CONVERT_TZ归一到同一时区再比。第三个陷阱是浮点摘要误差，金额用DECIMAL而非FLOAT做SUM，否则摘要永远对不上。把这些点写进校验规范，才能真的做到心里有底。