CHECKSUM TABLE 仅校验数据行 CRC32 值，不检查表结构、索引、AUTO_INCREMENT、字符集转换或浮点精度；执行前须确认 sql_mode、MySQL 版本、存储引擎三者一致；结果需结合 COUNT、聚合、抽样等交叉验证。
CHECKSUM TABLE 不是万能的数据完整性验证工具，它只校验数据行内容的 CRC32 值，不检查表结构、索引、AUTO_INCREMENT 值、字符集转换差异或浮点精度漂移。直接拿它当“数据没丢没改”的最终结论，容易漏掉真实问题。
执行 CHECKSUM TABLE 前必须确认的三件事
这条命令看似简单，但结果是否可信，取决于环境一致性：
- 源库和目标库的
sql_mode必须完全一致，否则隐式类型转换（如字符串转数字）会导致校验和不同 - 两库的 MySQL 版本最好相同，尤其涉及
FLOAT/DOUBLE字段时，不同版本对 NaN/Inf 的处理可能不同 - 确保两张表使用相同的存储引擎（如都是
InnoDB），MyISAM和InnoDB对 NULL 值的内部表示不同，校验和必然不等
CHECKSUM TABLE 返回值不一致的常见真因
看到 Checksum 数值不同，别急着重导，先排查这些低级但高频的问题：
- 目标库表里多了几条测试数据或迁移脚本残留记录——用
SELECT COUNT(*)先比行数 - 源库字段是
utf8mb4，目标库建表时误用了utf8，导致 emoji 或四字节字符被截断成?，CRC 自然不同 - 迁移时用了
mysqldump --skip-extended-insert，但目标库sql_mode含STRICT_TRANS_TABLES，某些隐式转换失败后跳过插入，造成行数缺失 - 表含
TIMESTAMP字段且跨时区迁移，未显式指定time_zone，导致值自动调整
CHECKSUM TABLE 该和谁比？不能只比一个数
单看一个 Checksum 值是否相等，信息量太弱。必须组合其他轻量查询交叉验证：
- 先跑
SELECT COUNT(*), MIN(id), MAX(id) FROM t—— 行数不对，校验和再一致也没意义 - 对关键数值字段做聚合比对：
SELECT SUM(amount), AVG(price), COUNT(DISTINCT user_id) FROM t，能暴露部分字段被批量清零或错位更新 - 抽样查具体记录：
SELECT id, name, updated_at FROM t WHERE id IN (1001, 5000, 9999)，人工或脚本比对，防字符集/时区/精度类隐式损坏
真正麻烦的不是 CHECKSUM TABLE 跑出不同，而是它跑出相同却掩盖了字段级损坏——比如所有 email 字段末尾被悄悄补了空格，或 JSON 字段里双引号被转义成 "。这种问题只能靠字段抽样和业务逻辑校验来揪出来。
