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';观察
Comment 列是否含 Crashed；对 MyISAM 表还可运行：myisamchk /var/lib/mysql/db_name/table_name.MYI（路径需按实际 datadir 调整）——若输出含
is not closed 或 record delete-link 错误，即为损坏。
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 自身恢复机制 + 备份还原。
Easily find JSON paths within JSON objects using our intuitive Json Path Finder
- 首先尝试强制启动：在
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）必须常态化运行，且备份有效性要定期验证。
