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 自身恢复机制 + 备份还原。 首先尝试强制启动：在
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）必须常态化运行，且备份有效性要定期验证。
