灵魂拷问：数据校验到底慢在哪？
十个人有九个会说「数据库查询」「网络 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。