根本原因是mysqld进程残留、主版本号不一致、属主权限不对；冷迁移需整目录替换，ibdata1承载数据字典等元数据，与ib_logfile*或.ibd文件LSN、校验、结构不匹配即拒启。
为什么冷迁移后MySQL启动报“InnoDB: Database page corruption”或直接卡在ibdata1加载阶段
根本原因不是文件拷错了，而是三个条件没同时满足：mysqld进程残留、主版本号不一致、属主权限不对。冷迁移本质是整目录替换，ibdata1作为InnoDB共享表空间，承载数据字典、undo日志、系统表等元数据，一旦与ib_logfile*或.ibd文件的LSN、页校验、结构定义不匹配，就会拒绝启动。
冷迁移前必须验证的三件事
别跳过检查，90%的失败源于这里：
- 确认源库已彻底停服：
ps aux | grep mysqld无残留进程；若用systemctl stop mysqld，再补一句kill -9 $(pgrep mysqld)防漏 - 目标MySQL主版本号必须一致：
mysqld --version输出如mysqld Ver 8.0.33，不能把5.7.x备份恢复到8.0.x，哪怕只是小版本（8.0.28→8.0.33）也建议先查官方兼容说明 - 目标数据目录属主必须是mysql用户：
chown -R mysql:mysql /var/lib/mysql，尤其注意复制后父目录（如/var/lib）权限是否继承了root
迁移后启动失败，别急着删ibdata1或加innodb_force_recovery
先做两件事，能解决70%的“假损坏”：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 检查
my.cnf中innodb_log_file_size是否与源库一致——不一致会导致LSN校验失败，错误日志里会出现InnoDB: Log file ./ib_logfile0 is of different size；此时应删掉ib_logfile0和ib_logfile1，再启动（MySQL会自动重建） - 确认
innodb_file_per_table设置是否相同：如果源库是OFF，所有表数据都在ibdata1里，那迁移时ibdata1必须完整替换，只拷.ibd文件毫无意义 - 若仍失败，再启用
innodb_force_recovery，但必须从=1开始试，每次只保留这一行配置，重启后立刻mysql -e "SHOW DATABASES;"验证连通性
当innodb_force_recovery=4能启动但导不出数据时怎么办
说明损坏已深入系统表空间，但还没到完全不可读的程度：
- 优先尝试单独移走疑似损坏的业务库目录（如
/var/lib/mysql/myapp），保留mysql/、sys/、performance_schema/，再启动——很多故障其实只影响某一个库 - 若错误日志明确指向某个
.ibd文件（如Cannot read first page of myapp/orders.ibd），可临时重命名该文件（mv orders.ibd orders.ibd.bak），再启动；InnoDB会忽略它，其他表仍可访问 - 绝对不要在
innodb_force_recovery >= 5下长期运行，=5会跳过undo日志扫描，=6跳过redo前滚，极大概率导致导出数据逻辑错乱，仅作最后抢救手段
真正麻烦的不是ibdata1损坏本身，而是你无法确定它到底损坏在哪一层：是页校验失败、LSN断裂、还是数据字典记录与物理页不对应。所以每一步操作前，务必先全量备份当前datadir——哪怕多花两分钟，也比修复中途崩溃强。
