MySQL表损坏分MyISAM与InnoDB两类：MyISAM表现为“Table is marked as crashed”等错误，可通过SHOW TABLE STATUS或myisamchk确认；InnoDB则多见启动失败或错误日志中的corruption提示，需依赖innodb_force_recovery与备份恢复。

MySQL 表损坏的典型现象与快速确认方法

遇到 Table is marked as crashed、Incorrect key file 或查询时直接报 ERROR 1016 (HY000)，基本可判定是 MyISAM 表损坏；InnoDB 表通常不会“标记为损坏”，但会表现为启动失败、mysqld 拒绝启动、错误日志中反复出现 InnoDB: Database page corruption 或 Assertion failure。优先检查 /var/log/mysql/error.log（或 Windows 下的 data/hostname.err），搜索 crash、corrupt、failed to open 等关键词。

确认损坏表后，先执行：

SHOW TABLE STATUS LIKE 'table_name';

myisamchk /var/lib/mysql/db_name/table_name.MYI

MyISAM 表的在线修复与离线修复选择

MyISAM 表支持两种修复方式：在线用 REPAIR TABLE（需有 ALTER 权限），或离线用系统级工具 myisamchk。前者更安全，但要求表未被其他线程写入；后者效率高、可控性强，但必须确保 MySQL 已停止或该表已 FLUSH TABLES 并加读锁。

• REPAIR TABLE db_name.table_name; —— 默认使用快速模式，适合轻度损坏；加 EXTENDED（REPAIR TABLE ... EXTENDED）会重建索引，耗时但更彻底
• 离线修复前务必停服或执行：

  FLUSH TABLES WITH READ LOCK;

  再在 shell 中运行：

  myisamchk --recover --force /var/lib/mysql/db_name/table_name.MYI

• 若提示 Key block size is wrong，说明索引结构严重错乱，需强制重建：

  myisamchk --safe-recover --force /var/lib/mysql/db_name/table_name.MYI

InnoDB 表损坏的应对策略：不依赖 myisamchk

InnoDB 表不能用 myisamchk，也不能用 REPAIR TABLE（执行会报错 Storage engine for the table doesn't support repair）。核心思路是靠 InnoDB 自身恢复机制 + 备份还原。

• 首先尝试强制启动：在 my.cnf 的 [mysqld] 段加入 innodb_force_recovery = 1，逐步尝试 1–6（数值越大恢复越激进，6 仅允许 SELECT），然后重启 MySQL。值为 1–3 时通常可导出数据
• 成功启动后，立即用 mysqldump 导出有效数据：

  mysqldump -u root -p --single-transaction --databases db_name > backup.sql

• 删库重建：停 MySQL → 删除对应 ibdata1 和 ib_logfile*（注意：这会清空所有 InnoDB 表空间！仅当无独立表空间或已备份好 .ibd 文件时才考虑）→ 启动 MySQL → 重建库并导入 dump
• 若启用了 innodb_file_per_table = ON，且 .ibd 文件完好，可尝试用 ALTER TABLE ... DISCARD TABLESPACE + IMPORT TABLESPACE 恢复单表（前提是 .ibd 未损坏且有对应 .cfg 元数据文件）

预防比修复更重要：几个容易被忽略的配置点

多数表损坏源于异常断电、磁盘满、内存故障或 MySQL 强制 kill，而非代码逻辑问题。以下配置能显著降低风险：

• 确保 innodb_doublewrite = ON（默认开启），它能防止页写入一半时崩溃导致数据页损坏
• 设置 sync_binlog = 1 和 innodb_flush_log_at_trx_commit = 1，牺牲一点性能换取事务持久性
• 禁用 skip-innodb-doublewrite 和 innodb_fast_shutdown = 2（应设为 1 或 0，避免 shutdown 时跳过刷脏页）
• 定期校验：对 MyISAM 表可跑 myisamchk --check --fast；InnoDB 无等效命令，但可通过 SELECT COUNT(*) + 对比 INFORMATION_SCHEMA.INNODB_SYS_TABLES 记录数做粗略一致性验证

真正棘手的不是修复动作本身，而是损坏发生后无法判断哪些行已丢失、哪些索引失效——所以任何线上环境，mysqldump 或物理备份（如 Percona XtraBackup）必须常态化运行，且备份有效性要定期验证。