彻底解决 MySQL 报错：Table is marked as crashed and last repair failed

2015-08-15 · Ryan · 发表评论

问题描述

在访问 WordPress 博客后台或执行某些数据库操作（如清理）时，可能会遇到以下错误：

Table 'xxx' is marked as crashed and last (automatic) repair failed

其中 xxx 为具体的数据库表名。此错误表明该 MyISAM 引擎的数据表索引文件（.MYI）已损坏，且 MySQL 的自动修复尝试失败。

原因分析

表损坏通常由以下原因引起：

服务器意外断电或重启。
MySQL 服务在写入过程中异常终止。
磁盘空间不足或出现磁盘错误。
MyISAM 存储引擎本身的稳定性问题（建议重要数据表使用 InnoDB）。

损坏后，表的索引信息丢失或错乱，导致无法正常读写。

修复前准备（重要）

在进行任何修复操作前，务必备份数据，以防修复过程中造成数据永久丢失。

1. 备份数据库文件

通过 SSH 连接到您的服务器，并定位到 MySQL 的数据目录（常见路径为 /var/lib/mysql/、/usr/local/mysql/data/ 或 /usr/local/mysql/var/）。

# 进入数据目录
cd /var/lib/mysql/
# 递归备份整个数据库文件夹（将 your_database_name 替换为实际的数据库名）
cp -r your_database_name your_database_name_backup

2. 停止 MySQL 服务

# 根据您的系统选择命令
# Systemd 系统（如 CentOS 7+, Ubuntu 16.04+）
systemctl stop mysqld
# 或
systemctl stop mysql

# SysVinit 系统
service mysql stop
# 或
/etc/init.d/mysqld stop

手动修复步骤

以下步骤假设您已备份并停止了 MySQL 服务。

步骤 1：进入损坏表所在目录

cd /var/lib/mysql/your_database_name

步骤 2：使用 myisamchk 工具修复

myisamchk 是 MySQL 自带的 MyISAM 表维护工具。

标准修复：尝试恢复表结构和数据。

myisamchk -r table_name.MYI

批量修复：修复数据库目录下所有 MyISAM 表。

myisamchk -r *.MYI

强制修复：当标准修复失败时使用，此模式更激进，可能修复成功，但也可能造成更多数据丢失。

myisamchk -r -f *.MYI

参数说明：

-r：恢复模式。尝试修复数据行和索引。
-f：强制模式。即使中间文件（.TMD）存在也强制执行。
*.MYI：通配符，匹配所有 MyISAM 索引文件。

步骤 3：重启 MySQL 服务并检查

# 启动服务
systemctl start mysqld
# 或 service mysql start

# 登录 MySQL 检查表状态
mysql -u root -p
USE your_database_name;
CHECK TABLE table_name;
REPAIR TABLE table_name; # 如果 myisamchk 修复后仍需在 MySQL 内修复

修复后的建议与预防

1. 转换存储引擎为 InnoDB

MyISAM 表易损坏且不支持事务。对于核心数据表（如 WordPress 的 wp_posts, wp_postmeta），建议转换为更稳定可靠的 InnoDB 引擎。

ALTER TABLE table_name ENGINE=InnoDB;

2. 定期优化与检查表

# 优化表（可回收空间并整理碎片）
OPTIMIZE TABLE table_name;
# 检查表状态
CHECK TABLE table_name;

3. 确保服务器稳定运行

配置 UPS（不间断电源）防止意外断电。
监控磁盘健康状态与剩余空间。
避免在 MySQL 运行中强制重启服务器。

如果手动修复失败

如果上述步骤无法修复，可以尝试：

从最近的完整备份中恢复该表。
使用 myisamchk --safe-recover 进行更安全的恢复（速度较慢）。
如果表结构已知但数据可丢弃，可尝试用 REPAIR TABLE ... USE_FRM 命令从 .frm 文件重建。
作为最后手段，从备份的 SQL 文件或其它副本中提取数据。

通过以上步骤，您应该能够解决大多数因 MyISAM 表损坏导致的“crashed”错误。定期备份和迁移至 InnoDB 是避免此类问题的最佳实践。