本文约 2,630 字，预计阅读 7 分钟。文中命令与配置均经过实测，可直接参考执行。
引言
很多站长第一次看到 “Table is marked as crashed and should be repaired” 这行英文报错时都会心里一紧，因为它通常伴随网站直接打不开或者某个功能失灵。这句报错的意思是”这张表被标记为已崩溃，需要修复”，MySQL 在检测到表文件内部状态不一致时，就会给它打上这个标记，之后的查询会被拒绝执行。它出现的场景很典型：服务器突然断电、被强制重启，磁盘写满，MySQL 进程被系统杀掉，或者主机商搬迁移机时数据没同步完。报错里通常会带上表名，比如 Table './db/wp_options' is marked as crashed and should be repaired。看到它不用慌，这是 MySQL 在保护数据，不是数据彻底没了，按本文步骤修复即可恢复。
故障原因分析
- 表在写入时被强制中断。这是最常见的原因。MyISAM 引擎的表没有事务保护，写数据一半时进程被杀，表头里的状态位就被标记成 crashed。InnoDB 表由于有重做日志和崩溃恢复，出现这个提示的概率低很多，但并非为零。
- 磁盘空间不足或磁盘故障。当磁盘写满，MySQL 无法完成刷盘操作，表文件就会不一致，被标记为崩溃。硬盘出现坏道也会导致同类问题。
- MySQL / MariaDB 进程异常退出。内存不足触发 OOM Killer、被运维误 kill、配置文件错误导致启动失败，都可能中断正在进行的写入。
- 不安全的关机或宿主机故障。云主机的物理机重启、断电，虚拟磁盘缓存丢失，都容易让表崩溃。
- 表文件被外部程序错误修改。比如有人直接拿超大的 .sql 文件在 phpMyAdmin 里导入，中途连接断开，表被留在中间状态。
分步解决方案
操作前的准备
第一步永远是备份。把整个数据库导出成 .sql 文件存到本地，或者对数据目录做快照。尤其是要修复的表里有重要内容时，备份是唯一的后悔药。同时尽量停止 WordPress 的写入，最简单的方法是把网站临时切换成维护模式，或者暂时关掉评论、缓存插件，避免修复过程中还有新数据写进来。
方法一：phpMyAdmin 图形化修复
- 登录 phpMyAdmin，左侧选中出问题的数据库。
- 找到报错里提到的那张表，注意它的真实前缀可能是 wp_ 也可能是你自定义的，比如 abc_posts。
- 勾选这张表，底部”选中项”里选择”修复表（Repair table）”，执行。
- 看返回结果，出现 “OK” 就成功了。若提示 “Table does not support repair” 之类，说明是 InnoDB 表，可参考方法三处理。
方法二：SQL 命令修复（推荐）
在 phpMyAdmin 顶部点”SQL”，把 wp_options 换成你实际报错的表名，逐条执行：
CHECK TABLE wp_options;
REPAIR TABLE wp_options;
CHECK TABLE wp_options;先 CHECK 确认状态，再 REPAIR 修复，最后再 CHECK 复查是否恢复 OK。如果一次没修好，可以再执行一次。对于 MyISAM 表，还可以启用扩展修复：
REPAIR TABLE wp_options EXTENDED;如果提示 Table 'xxx' doesn't exist，说明表前缀写错了，去数据库列表里核对真实表名。
方法三：SSH 命令行修复（InnoDB 表或大批量）
如果能登录服务器，用 mysql 客户端会更稳。先确认数据表对应的存储引擎：
SHOW TABLE STATUS LIKE 'wp_options';看 Engine 一列。MyISAM 用 REPAIR 即可；InnoDB 表若被标记 crashed，可以先尝试让 MySQL 自行恢复，或在停机状态下用 innodb_force_recovery 启动。一般做法是进入 mysql 命令行：
mysql -u 数据库用户 -p 数据库名然后：
REPAIR TABLE wp_options;如果单表修不好，可以用 myisamchk 工具，但必须先把 MySQL 服务停掉，否则会二次损坏：
myisamchk -r /var/lib/mysql/数据库名/wp_options具体路径按你的 MySQL 数据目录来。修完再启动 MySQL。
方法四：用 WP-CLI 一键检查修复
WordPress 用户最省事的办法。进入网站根目录执行：
wp db check
wp db repair第一条列出所有表状态，第二条自动修复。修完再跑一次 wp db check 确认。
修复后验证
无论用哪种方法，修好之后都要做三件事：一是重新访问网站前台和后台，确认功能正常；二是执行 CHECK TABLE 或 wp db check 复查；三是查一下磁盘空间和 MySQL 错误日志，确认不是空间导致的反复崩溃。
常见踩坑点
- 表名或前缀没换。报错里明明写着 wp_options，你却在修 wp_posts，白忙一场。以报错提示的表名为准。
- 对 InnoDB 表用 REPAIR 无效却以为没救。InnoDB 通常不需要也不支持这种修复，应该靠崩溃恢复或从备份还原。
- 不停 MySQL 就跑 myisamchk。在线操作会严重损坏表，务必先停服务。
- 只修了报错那一张，忽略同批损坏的表。断电往往同时打坏多张表，建议对整库做一次
wp db check。 - 修复前忘记备份。修复失败时没有回退余地，风险很高。
- 反复崩溃却不排查根因。如果同一张表天天崩，多半是磁盘快满或硬件有问题，要尽快联系主机商。
总结
“Table is marked as crashed and should be repaired” 本质上是 MySQL 在提醒你某张表需要一次修复，它并不是无法挽回的绝症。对 WordPress 站长来说，优先用 phpMyAdmin 的修复表功能或 wp db repair 命令处理，MyISAM 表用 SQL 的 REPAIR 语句，InnoDB 表则要谨慎对待、必要时从备份恢复。记住”先备份、再停写、后修复、终复查”的顺序，这类 MySQL表崩溃修复动作其实并不难，绝大多数情况下十分钟就能让网站重新跑起来。
