MySQL数据库恢复后出现数据不一致，通常说明备份或恢复过程存在隐患，不能仅靠“恢复成功”就认为数据完好。关键是要主动校验，而非被动等待问题暴露。
一、立即停写并确认恢复方式
恢复后发现不一致，首先要暂停应用写入，避免差异扩大。同时明确本次恢复用的是哪种方式：
物理备份（如xtrabackup）：需确认备份时是否启用--slave-info或
--safe-slave-backup，主从位点是否对齐 逻辑备份（mysqldump）：检查是否遗漏
--single-transaction或
--master-data，是否在备份中途有DDL操作 基于binlog的重放：核对起始position或GTID是否跳过关键事务，是否有过滤规则误删事件
二、用pt-table-checksum做主从一致性校验
这是Percona Toolkit中最常用的线上数据校验工具，适合主从架构下快速定位不一致表：
在主库执行：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;跳过，除非已确认是临时性冲突且无业务影响
不复杂但容易忽略：恢复后第一件事不是重启服务，而是跑一次校验。哪怕只校核心表，也能大幅降低线上故障概率。
