10GB InnoDB引擎MySQL数据库迁移数据正确性最优校验方案咨询

你的核心限制为「目标库存在非迁移来源的持续写入」、「部分表含大体积JSON字段」，以下方案可完全规避以上问题，兼顾校验准确性和性能：

方案核心思路 #

基于迁移快照的时间边界+主键分片校验，仅比对你迁移的特定范围数据，完全不涉及目标库后续写入的其他数据，同时优化大字段的哈希计算逻辑。

具体实施步骤 #

• 第一步：锁定迁移快照边界
  如果你用mysqldump时加了InnoDB迁移标准参数--single-transaction，可直接从dump日志、对应binlog位点拿到准确的快照时间点T，所有校验仅针对源库T时间点之前、目标库对应迁移的主键范围的数据，完全排除目标库其他写入数据的干扰。
• 第二步：主键分片批量校验
  选择表的自增主键/唯一非空主键作为分片键，按1000~10000行的粒度拆分校验范围，每一片用以下逻辑计算哈希：

  -- 提前调整会话参数避免GROUP_CONCAT长度溢出
  SET SESSION group_concat_max_len = 1000000;
  -- 分片计算校验值
  SELECT MD5(GROUP_CONCAT(MD5(CONCAT_WS('|', id, col1, col2, ..., MD5(大JSON列))) ORDER BY id)) AS slice_checksum 
  FROM 表名 
  WHERE id BETWEEN 分片起始ID AND 分片结束ID
  

  针对大体积JSON列单独预计算MD5值再参与拼接，既避免超长内容导致的GROUP_CONCAT溢出，也大幅降低拼接、哈希计算的性能开销。
• 第三步：异常快速定位
  如果某一片的源端和目标端校验值不一致，仅需要逐行比对该分片范围内的1000~10000行数据即可定位问题，不需要扫描全表，10GB规模的库全量校验通常可在30分钟内完成。
• 第四步：行数兜底校验
  单独统计源库快照时间点每张表的总行数，和目标库对应迁移主键范围的总行数做比对，作为哈希校验的补充兜底。

可选工具化优化 #

如果源库和目标库允许部署第三方工具，可直接使用pt-table-checksum，通过--where参数限定仅校验你迁移的主键范围/时间范围，工具会自动处理大字段适配、分片、性能限流的逻辑，无需手动编写SQL。

注意：所有校验操作建议在业务低峰期执行，避免对源库生产业务造成性能影响。

内容的提问来源于stack exchange，提问作者RKS