直接结论：这不是校验和本身的问题，而是迁移过程中.ibd文件被截断、字节错位或页头损坏导致innodb读取时校验失败；必须停写、验源、重传，确保二进制文件完整传输，而非调整校验算法或强行启动。
MySQL迁移时遇到“page checksum mismatch”错误怎么办
直接结论：这不是校验和本身的问题，而是迁移过程中.ibd文件被截断、字节错位或页头损坏导致InnoDB读取时校验失败。不能靠跳过校验或重算checksum来修复，必须回溯迁移操作链，定位哪个环节破坏了物理页结构。
为什么mysqldump或xtrabackup迁移后会出现checksum mismatch
常见原因不是数据内容出错，而是文件完整性在传输/解压/挂载阶段被破坏：
-
scp或rsync未加-p（保留权限）和-L（跟随符号链接），导致.ibd文件实际是空链接或大小为0 - Windows上传到Linux时用ASCII模式解压zip/tar包，把二进制
.ibd当文本处理，末尾多出\r\n或丢失字节 - 使用
cp -r复制运行中的MySQLdata目录（尤其Windows下），因文件句柄锁定导致.ibd复制不完整 - 云盘挂载异常（如NFSv3无强制同步）、磁盘I/O错误未报错但写入静默失败
快速验证是否真是checksum问题而非元数据不匹配
先别急着调innodb_checksum_algorithm或设innodb_force_recovery——那只是掩盖症状。执行以下检查：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 对比源库和目标库的
SHOW VARIABLES LIKE 'innodb_checksum_algorithm'，确保一致（推荐crc32，避免none） - 用
hexdump -C table.ibd | head -20查看目标.ibd前16字节：正常应为45 bf 00 00 00 00 00 00 ...（magic=0x45bf）；若开头是00 00 00 00或乱码，说明文件被清空或覆盖 - 运行
ls -l比对源/目标.ibd大小，差值超过16KB（一页）基本可判定传输损坏 - 查目标MySQL错误日志，确认报错是否含
InnoDB: page [page id: space=xxx, page no=yyy] checksum mismatch，且伴随failed file read
修复动作必须分三步走：停写→验源→重传
任何试图在损坏.ibd上直接启动MySQL的操作都可能触发doublewrite buffer校验失败，导致实例卡死。正确顺序是：
- 立即停止目标MySQL服务，不要设置
innodb_force_recovery强行启动 - 回到源库，用
mysqlcheck -c database_name table_name确认该表在源端状态正常（返回status OK） - 重新导出/传输：
– 若用mysqldump：加--single-transaction --routines --triggers，并用sha256sum校验SQL文件完整性
– 若用xtrabackup：必须用--copy-back而非手动cp，且备份前确认innobackupex --apply-log成功
真正容易被忽略的是：checksum mismatch几乎从不发生在逻辑迁移（dump/load）中，只出现在物理文件拷贝场景。只要传输层没做二进制保真，再多次重试也只会复现同样错误。
