GreatSQL社区

搜索

GreatSQL社区

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

GreatSQL社区 已有 15 次阅读2026-7-31 08:53 |系统分类:运维实战

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

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 立即注册

合作电话:010-64087828

社区邮箱:greatsql@greatdb.com

社区公众号
社区小助手
QQ群
GMT+8, 2026-8-1 01:47 , Processed in 0.021697 second(s), 9 queries , Redis On.
返回顶部