gt-checksum v4.0.2 来了，换个校验引擎，效率起飞

灵魂拷问：数据校验到底慢在哪？

十个人有九个会说「数据库查询」「网络 I/O」。没毛病，但还有个藏得很深的「时间小偷」——哈希计算。当表够大、字段够宽，它能悄悄偷走一大块 CPU。

这次 v4.0.2 就是来抓这个小偷的：我们把用了很久的 MD5 换成了飞快的 XXHash64，重点是 一行配置都不用改，升级就提速。

就问动心了没！

这版都改了啥

gt-checksum 是一款面向 MySQL / Oracle 的高并发数据校验与修复工具。v4.0.2 走的是「性能 + 体验」两条腿一起跑的路线，这次主要有四大变化：

• 换引擎：默认哈希从 MD5 升级到 XXHash64，部分场景中哈希计算快约 15-25 倍。
• 调解析：跨多行 SQL 改成整块一次性解析，长语句不再被反复「嚼」。
• 优输出：多值 INSERT 修复 SQL 改成「一 value 一行」，看着就舒服。
• 修顽疾：干掉了 table 模式下多行 INSERT 读回错乱这个老毛病。

被大表校验耗时折磨过的朋友，这版真的可以冲。

v4.0.1 vs v4.0.2 秒看懂

维度	v4.0.1	v4.0.2	变化
默认哈希算法	MD5（硬编码）	XXHash64	计算快 15-25 倍
算法可选	不可选	hashAlgorithm 参数切换	新增灵活性
跨多行 SQL 解析	逐行推进	整块一次性解析	长语句开销大降
多值 INSERT 输出	多行挤在一起	一 value 一行	更易读易 diff
table 模式多行 INSERT	读回可能错乱	完整正确还原	关键修复
checksum 核心测试	覆盖有限	单测补齐	回归有保障

哈希计算这块的速度差距，大概是这个感觉：

哈希计算耗时（越短越快，示意图）

MD5      ████████████████████████████  慢
XXHash64 █▏                            快（约 1/15 ~ 1/25）

端到端整体性能（受 DB 查询 + 网络 IO 制约）
v4.0.1   ██████████████████████
v4.0.2   ████████████▏          ↑ 提速约 30% ~ 50%

小提示：哈希只是校验链路的一环，端到端还得看数据库和网络的脸色，所以整体提速是 30%-50%，而不总是 15-25 倍。

1、XXHash64 荣升默认哈希

为啥要换掉 MD5

在 checkObject=data 模式下，gt-checksum 要给每一行数据算哈希再比对。过去这里写死用 MD5——它安全、通用，可问题是它为「密码学级别的抗碰撞」买了单。但大多数场景中，数据校验根本不需要那么强的安全性，我们只要「够快 + 碰撞概率足够低」就
行。

XXHash64 简直是为这个场景量身定做：主打一个「快」，属于非密码学高速哈希，哈希计算部分比 MD5 快约 15-25 倍。放到完整校验流程里，因为还受数据库查询和网络 IO 拖累，实测整体能提升 30%-50%。

怎么用？答案是——啥也不用做

真的，升级完不用动任何配置，默认就吃上 XXHash64 了。

想手动指定？新参数 hashAlgorithm 安排：

; 设置数据校验使用的哈希算法，可选 [xxhash64 | md5]，默认 xxhash64
; xxhash64：性能约为 MD5 的 15-25 倍，推荐使用
; md5：向后兼容旧版本行为
hashAlgorithm = xxhash64

有个坑必须提醒

哈希算法一换，新旧算法算出来的校验结果就没法直接对比了。所以记住两条：

• 全新校验任务 → 保持默认 xxhash64，无需修改配置参数。
• 要和旧版本历史结果对齐 → 显式设 hashAlgorithm = md5 回到从前。

一句话：只有当你要跟旧版本结果比对时，才需要把算法调回 md5。

2、SQL 解析整块化，长语句不再拖后腿

修复流程里，gt-checksum 得解析修复 SQL。老实现遇到跨多行的语句是「一行一行往前挪」，语句一长就得反复扫，白白浪费开销。

v4.0.2 改成整块一次性解析，一口气搞定，不再逐行反复嚼。语句越长、跨行越多，省得越多——批量 INSERT 的修复场景直接受益。

3、多值 INSERT 修复 SQL，一 value 一行

以前生成多值 INSERT 修复 SQL，多行数据全挤成一坨，人看着头大，后续处理还容易踩坑。

新版把每个 value 拆成独立一行：

INSERT INTO `db`.`tbl` (`id`, `name`) VALUES
(1, 'a'),
(2, 'b'),
(3, 'c');

排版一清爽，人工核对、diff 比对、翻日志，全都省心。

P.S，这是从 MySQL 2026.7 新版本中获得的灵感。

4、干掉 table 模式多行 INSERT 读回错乱

这是本次一个关键 Bug 修复，得重点说说。

table 模式下，修复 SQL 会先写进 stage 文件，再读回来执行。gt-checksum 靠「一行一条 SQL」的约定来切语句，可多行 INSERT 自带的换行偏偏破坏了这个约定，结果读回时语句被切错、内容全乱套。

v4.0.2 把写入和读回的逻辑理顺了，保证多行 INSERT 在 stage 文件里走一圈回来还是原样、完整正确。用 table 模式做数据修复的朋友，强烈建议尽快升级。

到底要不要升？对号入座

你的场景	建议
常规数据校验	直接升，默认 XXHash64 白嫖提速，配置一动不用动
需与旧版历史结果比对	升完显式设 hashAlgorithm = md5
用 table 模式做数据修复	优先升，修掉多行 INSERT 读回错乱
大量长语句 / 批量 INSERT 修复	升完解析开销更低，更丝滑

写在最后

v4.0.2 没搞什么花架子，而是把「校验快不快、修复稳不稳、输出清不清爽」这几件基本功打磨得更扎实。换引擎的提速开箱即得，多行 INSERT 的修复更是堵上了一个真实的正确性漏洞。

升级体验一波，有问题尽管砸过来，我们接着聊。

---

完整变更请见项目 CHANGELOG.md；参数详情参见 gt-checksum-manual.md。