Page corruption启动错误说明源备份或目标磁盘存在底层损坏，非配置问题；需检查备份日志、磁盘健康、RAID状态，并彻底清理ibdata1/ib_logfile*等系统文件后再还原。
物理还原后启动提示 Page corruption，说明还原过程本身没出错，但源备份或目标磁盘存在底层损坏——InnoDB 在加载表空间时校验失败，不是配置或权限问题，而是数据页（16KB）内容与校验和不匹配。
还原前备份文件就已损坏
常见于：xtrabackup 备份中途磁盘 I/O 错误、NFS 挂载点断连、S3 上传/下载校验失败。错误日志里常带 Database page corruption detected at page NNNNN 或 failed file read of table db_name.table_name。
- 用
xtrabackup --decompress后立即执行innobackupex --apply-log，过程中若报某.ibd文件页校验失败，该备份不可用 - 别跳过
--apply-log阶段直接复制还原——未回滚未提交事务、未合并插入缓冲的备份，启动时必然触发页校验异常 - 检查备份生成时的原始日志：
grep -i "corrupt\|error.*page" /path/to/backup/xtrabackup_logfile
还原目标磁盘有坏道或缓存异常
即使备份完好，还原到故障硬盘、RAID 降级盘、或开启 write-back 缓存但电池失效的 RAID 卡上，写入过程可能静默出错，导致 .ibd 或 ibdata1 中某些页被写花。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 还原后、启动前，先运行
sudo smartctl -a /dev/sdX查磁盘健康状态；用sudo badblocks -v /dev/sdX扫描坏块（需卸载） - 若使用 RAID，确认
cat /proc/mdstat显示 clean，且megacli -AdpBbuCmd -GetBbuStatus -aALL返回 Battery State: Optimal - 临时关闭 OS 级缓存：
echo 3 | sudo tee /proc/sys/vm/drop_caches，再重启 mysqld 测试是否仍报错——有时是内核 page cache 污染导致误判
还原后未清空旧系统表空间残留
最易忽略的一点：物理还原只覆盖 .ibd 文件，但 ibdata1（系统表空间）、ib_logfile*（redo 日志）仍为旧文件。若原库崩溃前 ibdata1 已损坏，还原新表后启动仍会卡在系统页校验。
- 还原前必须删除整个数据目录下除
.ibd外的所有 InnoDB 系统文件：rm -f ibdata1 ib_logfile* undo_001 undo_002 - 还原后首次启动前，确保
my.cnf中明确设置innodb_data_file_path = ibdata1:12M:autoextend，避免复用旧配置指向损坏的ibdata1 - 如果还原的是单库，而
ibdata1被其他库共用，不能直接删——此时应改用逻辑还原（mysqldump），而非物理还原
真正棘手的不是“怎么启动”，而是“哪一页坏了、为什么坏”。只要日志里出现 page number= 或 space= 编号，就说明损坏已定位到物理位置，这时候再试 innodb_force_recovery 只是抢救手段，不是修复路径。
