MySQL恢复后数据不一致需立即停写并确认恢复方式，用pt-table-checksum校验主从、checksum table比对单实例，定位后谨慎修复。

MySQL数据库恢复后出现数据不一致，通常说明备份或恢复过程存在隐患，不能仅靠“恢复成功”就认为数据完好。关键是要主动校验，而非被动等待问题暴露。

一、立即停写并确认恢复方式

恢复后发现不一致，首先要暂停应用写入，避免差异扩大。同时明确本次恢复用的是哪种方式：

• 物理备份（如xtrabackup）：需确认备份时是否启用--slave-info或--safe-slave-backup，主从位点是否对齐
• 逻辑备份（mysqldump）：检查是否遗漏--single-transaction或--master-data，是否在备份中途有DDL操作
• 基于binlog的重放：核对起始position或GTID是否跳过关键事务，是否有过滤规则误删事件

二、用pt-table-checksum做主从一致性校验

这是Percona Toolkit中最常用的线上数据校验工具，适合主从架构下快速定位不一致表：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 在主库执行：pt-table-checksum --no-check-binlog-format --replicate=test.checksums h=主库IP,u=用户,p=密码
• 校验结果会写入test.checksums表，再用pt-table-sync --print查看差异SQL（不直接同步）
• 注意：需确保主从复制正常、从库未延迟；若用GTID，要加--recursion-method=dsn指定DSN表

三、单实例数据校验：用checksum table + 行数比对

对于无从库的单机恢复场景，可分层验证：

• 查表行数：SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='db_name'; 与备份前记录对比
• 逐表校验CRC：CHECKSUM TABLE t1; 获取整表哈希值，和备份时的checksum比对（注意：该值受排序、字符集、NULL处理影响，仅作快速筛查）
• 抽样校验关键字段：SELECT MD5(GROUP_CONCAT(CONCAT(id, '-', name) ORDER BY id)) FROM t1 LIMIT 10000; 比对摘要值

四、修复不一致：谨慎选择策略

定位到具体表/行后，修复动作必须可逆、可审计：

• 小范围差异：导出差异数据，用INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO回填
• 整表不一致：优先重刷该表（mysqldump单表 + source），比全库重搭更安全
• 禁止直接在从库执行STOP SLAVE; SET GLOBAL sql_slave_skip_counter=1;跳过，除非已确认是临时性冲突且无业务影响

不复杂但容易忽略：恢复后第一件事不是重启服务，而是跑一次校验。哪怕只校核心表，也能大幅降低线上故障概率。