本文约 2,878 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言
辛辛苦苦运营的 WordPress 网站，某天打开突然变成一片空白，后台弹出”建立数据库连接时出错”或者”Error establishing a database connection”，用 phpMyAdmin 一打开又看到某张表旁边标着红色的”已损坏”。这种数据库损坏的故障，多半发生在服务器被强制关机、磁盘空间写满、MySQL 进程被 OOM 杀掉，或者主机商迁移数据之后。损坏最常出现在 wp_posts（存放文章）和 wp_options（存放站点配置）这两张表上，因为它们读写最频繁。一旦它们出了问题，网站要么直接打不开，要么首页能开但内容全丢、设置全乱。别慌，绝大多数表损坏都能修复，本文按保姆级步骤带你一步步救回来，操作前请务必先备份。
故障原因分析
- MySQL 写入过程中被中断。InnoDB 有崩溃恢复机制，MyISAM 相对脆弱。如果服务器断电、被强制重启，正在写入 wp_posts 或 wp_options 的查询没完成，表文件（.MYD/.MYI）就会处于不一致状态，表现为”marked as crashed”或”已损坏”。
- 磁盘空间写满或达到 inode 上限。当服务器磁盘满时，MySQL 无法完成写入也无法正常刷盘，表会直接损坏。这类情况往往同时伴随其他报错，比如”Disk full”。
- phpMyAdmin 操作意外中止。在网页里执行大表的修复、优化或导入时，浏览器超时、连接被掐断，MySQL 进程被中断在写表过程中，从而把表弄坏。
- wp_options 单独损坏通常和插件、主题有关。autoload 选项被大量垃圾数据撑大，或者某个插件反复写坏数据，导致该表索引损坏。wp_options 一旦损坏，站点地址、主题设置、激活插件列表都可能读不出来。
- 主机环境异常或版本不兼容。某些虚拟主机限制单表大小、限制了修复权限，或者 MySQL/MariaDB 版本升级后旧的表结构没处理好，也会引发读取异常。
分步解决方案
第零步：先备份，再动手
这一条无论何时都不能跳过。用 phpMyAdmin 或主机后台把整个数据库导出成 .sql 文件；如果服务器上有文件管理工具，最好再对 MySQL 数据目录做一份快照。备份没做完，后面的操作一律不要做。
方法一：用 phpMyAdmin 修复（适合新手、虚拟主机）
- 登录主机控制面板，进入 phpMyAdmin。
- 左侧点击你的 WordPress 数据库，能看到所有 wp_ 开头的表。
- 找到标红或提示”已损坏”的表（常见就是 wp_posts、wp_options），在表名前的复选框上打勾。
- 页面下方”选中项”下拉框里，选择”修复表”（Repair table），点”执行”。
- 结果区如果显示”OK”，说明修复成功。若同一张表反复损坏，建议顺手也执行一次”优化表（Optimize table）”。
需要注意：这里的表前缀不一定是 wp_，很多站点出于安全考虑改成了别的，比如 wpxx_posts、wp2_posts。你在 phpMyAdmin 里看到的实际名字是什么就用什么，后面 SQL 里的 wp_ 同理要替换成你自己的前缀。
方法二：用 SQL 命令修复（更彻底）
在 phpMyAdmin 上方点击”SQL”标签，粘贴执行。修复单张表：
REPAIR TABLE wp_posts;
REPAIR TABLE wp_options;如果只有一张表坏了，直接替换表名即可。想一次性检查并修复库里的所有表，可以逐个执行，或者用下面的方式查看状态：
CHECK TABLE wp_posts, wp_options;当 CHECK TABLE 返回 Table is marked as crashed and should be repaired，就说明必须修复。REPAIR 之后再用 CHECK TABLE 复查，返回 status 为 “OK” 才算修好。
MyISAM 表如果损坏严重，普通的 REPAIR 修不好，可以用扩展模式：
REPAIR TABLE wp_posts EXTENDED;如果连扩展模式都不行，说明表文件本身受损，最稳妥的办法是从备份里单独恢复这张表。
方法三：用 WP-CLI 修复（有 SSH 权限时最省事）
登录服务器后进入网站根目录，依次执行：
wp db check
wp db repairwp db check 会列出所有表的状态，wp db repair 会自动修复有问题的表。相比手动点鼠标，命令方式更适合批量处理，也方便写进定时任务里定期检查。
方法四：表损坏到无法修复时的兜底方案
如果 REPAIR 反复失败，或者表数据已经乱到无法读取，按下面顺序来：
- 从最近一次完整备份中，只恢复损坏的那张表，而不是整库覆盖，避免把新文章一并回退掉。
- 如果只有 wp_options 损坏且没有备份，可以新建一个空白 WordPress 环境，导出其 wp_options 结构，再把你能从旧表里读出来的行逐条补回；重点是 siteurl、home、active_plugins、template、stylesheet 这几个关键选项。
- wp_posts 彻底损坏且无备份时，只能寄希望于搜索引擎快照、RSS 缓存或数据库文件残留，从里面抢救内容，然后把文章重新导入 WordPress。
第末步：修复后的收尾检查
修复完成后，登录后台确认文章列表正常、设置页能打开、前台页面能访问；再执行一次：
CHECK TABLE wp_posts, wp_options;确认返回 OK。最后把这次操作也纳入定期备份计划，避免下次再从零开始。
常见踩坑点
- 不备份直接修复。REPAIR 在极端情况下可能让数据更难恢复，先导出再动手，永远是铁律。
- 表前缀写错。文章里的 wp_ 只是默认前缀，你的站点如果改过前缀，SQL 里必须换成实际前缀，否则会提示”表不存在”。
- 在 phpMyAdmin 里对超大表做修复。几百万行的表在网页里修复容易超时中断，反而加重损坏，建议改用命令行或 WP-CLI。
- 把”优化表”当”修复表”用。优化只整理碎片，不能修复损坏，两者不要混淆。
- 只修一张表就以为万事大吉。wp_posts 和 wp_options 常常一起损坏，修复后要把所有 wp_ 表都检查一遍。
- 修复后立刻删备份。至少保留一周的备份，确认站点稳定运行后再清理。
总结
WordPress 数据库损坏虽然吓人，但 wp_posts 和 wp_options 的表损坏大多是可逆的，关键是”先备份、再修复、后复查”这三步。新手用 phpMyAdmin 的”修复表”，有服务器权限的用 WP-CLI，配合本文给出的 REPAIR 与 CHECK 语句，绝大多数 WordPress数据库损坏修复都能在十分钟内解决。修好之后，别忘了配置自动备份并定期检查磁盘空间，把损坏概率降到最低。
