mysql 表损坏的典型现象与快速确认方式
MySQL 表损坏通常不是静默发生的，而是会在查询、插入或优化操作中暴露。最直接的信号是执行
SELECT或
REPAIR TABLE时抛出类似
ERROR 1017 (HY000): Can't find file: 'xxx.frm' (errno: 2)或
ERROR 126 (HY000): Incorrect key file for table 'xxx.MYI'; try to repair it的错误。InnoDB 表更常表现为崩溃后无法启动，错误日志里出现
InnoDB: Database page corruption on disk。
确认是否真损坏，优先查
mysqlcheck：
mysqlcheck -u root -p --check --all-databases
它会列出所有表的状态，
status列显示
OK、
error或
warning。不要跳过这步——很多“修复失败”其实源于误判，比如只是权限不足或磁盘满导致临时写入失败。
MyISAM 表用 REPAIR TABLE 的实际限制
REPAIR TABLE对 MyISAM 表有效，但前提是
.MYI（索引文件）未彻底丢失或严重错位。它本质是重建索引，不恢复被截断的数据页。 必须在表未被其他进程锁住时运行；否则报
ERROR 1194 (HY000): Table 'xxx' is marked as crashed and should be repaired却修不动 仅支持
QUICK（只修复索引）、
EXTENDED（逐行扫描修复）两种模式：
REPAIR TABLE xxx EXTENDED更彻底，但耗时长、需双倍磁盘空间 如果
.MYD（数据文件）已损坏，
REPAIR可能成功返回，但后续
SELECT仍报
ERROR 1034 (HY000): Incorrect key file...—— 这说明数据本身不可信，不能继续用
InnoDB 表没有 REPAIR TABLE，靠什么恢复一致性？
InnoDB 不提供
REPAIR TABLE，因为它的崩溃恢复机制内建在引擎层。真正有效的手段只有三条路径： 重启 MySQL：若配置了
innodb_force_recovery = 1~
6，可尝试逐步提升该值（从 1 开始），让 InnoDB 跳过某些恢复步骤以启动服务，再用
mysqldump导出还能读取的数据 从最近的
ibdata1+
.ibd备份恢复：这是唯一能保证完整一致性的做法。注意：
innodb_file_per_table = ON时每个表有独立
.ibd，但
ibdata1仍存系统表空间和事务元数据，二者必须版本匹配 用
mysqlbinlog回滚到故障前：前提是开启了 binlog 且格式为
ROW，并知道确切的故障时间点。命令形如：
mysqlbinlog --start-datetime="2024-05-20 10:23:00" mysql-bin.000001 | mysql -u root -p
别信网上“用
ALTER TABLE ... ENGINE=InnoDB重建表就能修复”的说法——这只对轻微元数据不一致有效，对页面级损坏毫无作用，还可能触发隐式锁等待甚至死锁。
修复后验证数据一致性的关键检查点
修复完成不等于数据可用。必须验证三件事：
主键/唯一索引无重复：执行SELECT COUNT(*) FROM xxx GROUP BY id HAVING COUNT(*) > 1，尤其关注自增列或业务主键 外键约束是否生效：InnoDB 表修复后，
FOREIGN_KEY_CHECKS默认为 1，但需手动确认约束定义还在：
SHOW CREATE TABLE xxx中应包含
CONSTRAINT `fk_name` FOREIGN KEY (...) REFERENCES ...统计信息是否过期：修复后
ANALYZE TABLE xxx必须执行，否则优化器可能基于旧的行数估算生成低效执行计划
最容易被忽略的是时间戳字段。比如修复过程中跳过了部分事务，
updated_at可能全变成 0000-00-00 或远早于业务实际时间——这类逻辑一致性，工具查不出来，得结合业务日志交叉比对。
