数据一致性校验必须分阶段、按表粒度、结合上下文执行，仅比count(*)或依赖dts内置校验易导致静默失败，如字段错位、时区偏差、json格式差异等未被发现，引发生产事故。
校验不是“跑完就完事”，而是必须分阶段、带上下文、按表粒度执行——否则漏掉的那几行，上线后就是生产事故。
为什么 COUNT(*) 和 DTS 内置校验不能信
只比 COUNT(*) 会掩盖字段值错位、JSON 格式差异、时区转换偏差；DTS 内置校验在源库执行 ALTER TABLE 后可能跳过整张表，但控制台只显示“校验完成”，不提示“user_profile 表未参与”。这类静默失败在跨云或异构迁移中尤其常见。
- 源库
TINYINT(1)映射到目标库BOOLEAN，0/1 被转成FALSE/TRUE，业务层取值逻辑崩了 - 源库用
CST时区写入NOW()，目标库用UTC+8解析，同一时间戳哈希值完全不同 - JSON 字段里多一个空格、少一个换行，
MD5(CONCAT(*))直接不等，但COUNT(*)看不出
pt-table-checksum 的三个硬性前提必须手动确认
这个工具仍是目前最可靠的行级校验方案，但它不是黑盒，缺一不可：
- 目标库必须能模拟从库行为：至少要配置
replicate_do_table或创建percona.checksums表，并允许REPLACE INTO写入校验结果 - 必须关闭 GTID 自动跳过：
SET GLOBAL sql_slave_skip_counter = 0，否则某条事务被跳过，后续所有分片（chunk）校验都会失效 - 无主键/无唯一键表默认被跳过；若必须校验，得加
--chunk-index=created_at，且该字段必须非空、高基数、无大量重复值
抽样 MD5 比对时字段拼接的实操细节
直接 SELECT MD5(CONCAT(col1, col2)) 是典型反模式。MySQL 对 NULL、浮点精度、字符集、JSON 空白的处理会让哈希失真：
- 统一处理
NULL：CONCAT(IFNULL(col1, 'NULL'), '|', IFNULL(col2, 'NULL')) - 金额类字段先转字符串：
CAST(amount AS CHAR)，避免99.9在不同库解析为99.90000000000001 - JSON 字段必须标准化：
IF(JSON_VALID(json_col), JSON_COMPACT(json_col), json_col)（MySQL 8.0+），或降级用REPLACE(REPLACE(json_col, ' ', ''), '\n', '') - 时间字段显式转时区：
CONVERT_TZ(created_at, '+00:00', '+08:00')，确保两边基线一致
校验时机必须匹配迁移阶段
不是“能跑就行”，而是要和你的同步状态严格对齐：
- 全量导入刚结束？必须停写源库和目标库，再跑独立校验脚本——否则分片边界被新写入污染，部分行会被重复或遗漏
- 正在用 Kafka 做 CDC 增量同步？校验点要绑定
binlog position或LSN，只比对“截至该位点”的快照，而不是当前实时状态 - 准备切流前最后一轮校验？必须同时做“行数 + 关键单据抽样 + 业务逻辑验证”（比如查 100 笔订单的
status和pay_amount是否完全一致）
最容易被忽略的是：校验本身会加重源库负载，尤其是大表分片扫描。务必在业务低峰期执行，且避免和备份、慢查询分析任务撞车。
