CHECKSUM TABLE 仅检测物理损坏，不保证逻辑一致；MyISAM 精确校验，InnoDB 默认只校验主键索引页；EXTENDED 可增强覆盖但会锁表；NULL 返回值表明严重损坏；COUNT(*) 行数一致不等于数据正确；MD5(GROUP_CONCAT()) 抽样校验关键字段更实用；静默失败（如 ENUM 变更、时区偏移、字符集降级）最难发现，需嵌入业务规则断言。
用 CHECKSUM TABLE 快速发现表级数据损坏
CHECKSUM TABLE 不校验逻辑一致性，只检测物理层面是否被意外修改（比如恢复时写入截断、页损坏、binlog回放错位）。它对 MyISAM 表是精确校验，对 InnoDB 表默认只校验主键索引页的校验和（不包含二级索引或溢出列），所以结果为 0 仅表示“没发现底层页损坏”，不代表数据逻辑正确。
实操建议：
- 恢复后立刻对每张表执行
CHECKSUM TABLE `db_name`.`table_name`，记录结果；对比备份前同表的 checksum 值（需提前存档） - InnoDB 表想增强覆盖，加
EXTENDED参数：CHECKSUM TABLE `t` EXTENDED，但会锁表 + 全表扫描，生产环境慎用 - 遇到
NULL返回值，说明表损坏严重，SHOW ENGINE INNODB STATUS查Corruption相关段落
为什么单靠 SELECT COUNT(*) 不够可靠
行数一致 ≠ 数据一致。常见陷阱包括：空值字段被批量置零、时间戳全变成默认值、JSON 字段被截断但长度未变、字符集转换导致乱码后仍占相同字节数——这些都不会影响 COUNT(*) 结果。
使用场景要分清：
- 仅用于快速兜底：恢复后跑一遍
SELECT COUNT(*) FROM `t`，和备份日志里的行数比对，能抓出明显漏导/多导问题 - 不能替代字段级验证：比如
WHERE created_at > '2024-01-01'的行数突降，可能只是某批数据的时间字段全被刷成'0000-00-00' - 大表慎用：InnoDB 的
COUNT(*)在无 WHERE 条件时可能走索引统计（快），也可能退化为全表扫描（慢），取决于版本和innodb_stats_persistent设置
组合验证：用 MD5(GROUP_CONCAT()) 抽样校验关键字段
这是平衡精度与开销的实用方案——不校验全部行，但确保核心字段的分布和内容没漂移。原理是把排序后的关键字段拼接再哈希，只要任意一行、任意字段变化，MD5 就不同。
实操注意点：
- 必须显式
ORDER BY，否则GROUP_CONCAT顺序不确定，哈希结果不可复现 - 字段选有区分度的，避免全 NULL 或常量列；敏感字段（如密码）跳过
- 示例语句：
SELECT MD5(GROUP_CONCAT(CONCAT(id, '-', name, '-', status) ORDER BY id SEPARATOR ',')) FROM users; - 超大表加
LIMIT抽样，比如只取最新 10 万行：... FROM (SELECT * FROM orders ORDER BY id DESC LIMIT 100000) t
容易被忽略的隐性破坏点
恢复过程最危险的不是报错，而是“静默失败”：SQL 没报错，数据看起来也完整，但业务逻辑已失效。
典型例子：
-
ENUM或SET列在跨版本恢复时，定义变更导致值被转成空字符串或默认项，COUNT(*)和CHECKSUM都无法感知 - 外键约束在恢复时被禁用（
FOREIGN_KEY_CHECKS=0），关联数据实际已断裂，但单表校验全绿 - 时区设置不一致：备份时用
SYSTEM时区导出DATETIME，恢复时 MySQL 配置为+08:00，所有时间偏移 8 小时，checksum 和行数完全不变 - 字符集降级：从
utf8mb4恢复到只支持utf8的实例，四字节 emoji 变成?或截断，但字段长度和非空约束仍通过
真正关键的不是“有没有差”，而是“差在哪里、影响哪些业务路径”。校验脚本里得嵌入业务规则断言，比如“status 为 'paid' 的订单，amount 必须 > 0”，这种没法靠通用命令覆盖。
