MySQL CHECKSUM TABLE 怎样比较两张表的数据摘要

如果你要判断迁移、备份恢复或副本同步前后的两张表是否出现明显差异，MySQL 自带的 CHECKSUM TABLE 可以先返回每张表的数据摘要。最小写法是把两个表放进同一条语句中；摘要不同，通常说明表内容或行存储状态不同，但摘要相同也不能当作绝对一致证明。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/checksum-table.html

本文只讨论摘要比较和结果判读，不把它包装成加密哈希或完整的数据校验系统。

先用 CHECKSUM TABLE 读取两张表的摘要

第一步先确认比较对象是两张真实表，并且比较前提尽量一致：表结构、数据范围、字符集和存储引擎要能对应起来。语句可以同时列出两个表名：

-- 同一实例中比较源表和对照表的摘要
CHECKSUM TABLE app.orders, app.orders_copy;

-- 需要明确采用逐行计算语义时使用 EXTENDED
CHECKSUM TABLE app.orders, app.orders_copy EXTENDED;

返回结果通常包含 Table 和 Checksum 两列。先看每个表对应的表名，再比较摘要值；不要只复制第二列而忘记它属于哪张表。

按 QUICK、EXTENDED 和表类型解释结果

QUICK 不是“更快的 InnoDB 校验”。它只对满足条件的 MyISAM 表有快速摘要路径；InnoDB 不支持 QUICK，这时不能把返回的 NULL 当成空表。对 InnoDB 以及不满足快速条件的表，应使用默认计算或 EXTENDED：

-- 仅在确认表是支持快速摘要的 MyISAM 时使用 QUICK
CHECKSUM TABLE legacy_orders, legacy_orders_copy QUICK;

-- 对 InnoDB 等表按行计算摘要，耗时可能随表大小增长
CHECKSUM TABLE app.orders, app.orders_copy EXTENDED;

排查时可以先记录两张表的存储引擎，再解释参数结果。这样看到 NULL 时，优先检查引擎和警告信息，而不是立即判定数据不一致。

看到不同摘要和相同摘要时分别怎么判断

两张表的摘要不同，通常可以作为“需要继续排查”的证据，常见原因包括数据行不同、行格式不同，或者比较的对象并非同一批数据。摘要相同只能说明这次摘要计算得到相同值；官方文档明确提醒，使用的函数不是保证无碰撞的密码学哈希，因此不能据此证明两张表逐字节或逐行绝对相同。

如果表经历过版本升级、存储引擎变更或行格式变更，即使业务数据看起来没有变化，摘要也可能变化。做迁移前后对比时，应把 MySQL 版本、表定义和存储引擎一起记录。对大表还要预留读取时间，因为逐行计算不是零成本操作，并且相关表可能受到读锁影响。

另外，视图不适合作为这个比较对象：对视图执行时摘要值可能为 NULL 并产生警告；不存在的表也会返回 NULL 和警告。执行账号还需要目标表的 SELECT 权限。

一张清单收尾：摘要比较之后还要做什么

可以把 CHECKSUM TABLE 看作低成本的差异筛查入口：它适合快速发现“可能不一样”，不适合替代备份恢复演练、逐行核对或业务字段级校验。

相关问题

CHECKSUM TABLE 能直接比较不同服务器上的两张表吗？

它返回的是当前连接能够访问到的表摘要，不能因为把两个表名写在一条语句里，就把不同服务器自动变成一次跨服务器比较。跨服务器场景应分别取得摘要，并记录版本、引擎和表结构等比较前提，再对结果做人工或脚本比对。

为什么 CHECKSUM TABLE 的值会在升级后变化？

摘要计算依赖表的行存储格式，MySQL 版本或行格式发生变化时，计算结果可能变化。升级前后看到不同值时，应先排除格式变化，再决定是否继续做数据内容级校验。