innodb表空间损坏不能修复，只能抢救数据：报“corrupted page found”等属物理页损坏，需用innodb_force_recovery逐级（1-4）只读导出；报“tablespace is missing”则为文件丢失或权限问题，应检查.ibd存在性及权限。
不能直接“修复”Corruption页，只能抢救还能读的数据——InnoDB没有像MyISAM那样的REPAIR TABLE命令，页损坏后唯一可行路径是启用innodb_force_recovery导出、重建表或换实例。
怎么确认是Corruption页损坏，而不是文件丢失或权限问题
错误日志里出现Corrupted page found、Database page corruption on disk或Failed to read page，基本就是物理页损坏；如果报Tablespace is missing for table或Operating system error number 2，大概率是.ibd被删、移动或chmod 000了。别跳过这步——误判类型会导致操作全错。
顺手跑一次：mysqlcheck --check --extended --all-databases。若只有个别表报error: record is corrupted，说明是单个.ibd损坏；若大面积报错，优先怀疑ibdata1或系统表空间元数据层崩溃。
再查SHOW ENGINE INNODB STATUS\G里的LATEST DETECTED CORRUPTION段，它会明确指出出问题的表名和文件路径，比SHOW CREATE TABLE更可信。
innodb_force_recovery该设几？从1开始试，别跳
这个参数不是越大越好，也不是设了就能导出全部数据。它从1到6逐级放宽崩溃恢复限制，但每升一级，跳过的结构就越多：
-
innodb_force_recovery = 1：跳过损坏的索引记录，允许SELECT，仍可能接受INSERT/UPDATE（不推荐） -
innodb_force_recovery = 2：停掉purge线程和change buffer合并，只允许SELECT，禁止写操作 -
innodb_force_recovery = 3：忽略未提交事务，ACID保障失效，但能绕过事务回滚失败导致的启动卡死 -
innodb_force_recovery = 4及以上：禁用插入缓冲、清除线程甚至重做日志应用，极易引发二次崩溃，生产环境慎用
实操建议：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 必须从
1开始试，不能跳着设——2可能比1更卡死，因为跳过的恢复逻辑不同 - 加完配置后，一定要停掉MySQL（宝塔点“停止”，或
systemctl stop mysqld），再手动启动：/www/server/mysql/bin/mysqld --defaults-file=/www/server/mysql/etc/my.cnf & - 启动成功后立刻执行：
mysqldump -u root -p --all-databases > /root/all.sql；导出卡住就降级重试，别硬扛 - 导完马上注释掉
innodb_force_recovery行，否则写操作全被拒绝
导出失败或部分数据读不出来怎么办
当mysqldump卡在某张表，或SELECT * FROM t LIMIT 100报错而LIMIT 10正常，说明损坏页位于中间区域。这时可用二分法定位：
- 先用
SELECT * FROM t LIMIT 50试探，再试LIMIT 75，逐步逼近报错边界 - 确认损坏范围后，改用
mysqldump --where="id t_part1.sql分段导出 - 对无法读取的页，别强求——InnoDB不会告诉你哪一行坏了，它只在读到坏页时崩溃
如果连SELECT COUNT(*)都失败，说明聚集索引根页或FSP_HDR页已损，此时innodb_force_recovery = 3或4可能是唯一出路，但要接受部分数据永久不可读。
重建表时为什么IMPORT TABLESPACE失败
ALTER TABLE t IMPORT TABLESPACE报Invalid tablespace或Tablespace mismatch，不是你拷错了文件，而是InnoDB在校验space_id、server_uuid、LSN这些隐藏字段。这些值在ibdata1重建后已变，而老.ibd里还存着旧值。
安全做法是：
- 确保
my.cnf里有innodb_file_per_table = ON（MySQL 5.7+ 默认开） - 备份整个
datadir后，只删ibdata1、ib_logfile0、ib_logfile1——其他.ibd和.frm必须原样留下 - 重启MySQL，它会自动生成新
ibdata1和日志文件 - 用
CREATE TABLE建空表，再执行ALTER TABLE t DISCARD TABLESPACE→ 拷入老.ibd→ALTER TABLE t IMPORT TABLESPACE
真正容易被忽略的是：导入前必须保证server_uuid没变（比如没重装MySQL），且.ibd文件的space_id与当前INFORMATION_SCHEMA.INNODB_SYS_TABLES中该表记录一致——不一致就得用xtrabackup --prepare或底层页解析工具重写头信息。
