后台突然打不开，页面只剩一行 “Error establishing a database connection”，或者提示 “One or more database tables are unavailable”。刷新几次也没用，但服务器本身活得好好的——这种情况八成是数据库表坏了。表损坏最常见的诱因就三个：断电或强制重启导致写入中断、磁盘写满、MySQL 进程被 OOM Killer 杀掉。下面按我实际排障的顺序走一遍。
第一步：先确认是不是真的坏表
别急着修，先看日志。MySQL 的错误日志一般在这两个位置之一：
tail -n 100 /var/log/mysql/error.log
tail -n 100 /var/lib/mysql/$(hostname).err如果里面出现 Table './wp_db/wp_options' is marked as crashed 或者 InnoDB: Database page corruption，那就实锤了。顺手再确认一下磁盘：
df -h
df -i我见过好几次，表没坏，纯粹是分区 100% 满了导致 MySQL 无法写临时文件。这种情况清出空间重启服务就恢复了，不用折腾修复。
第二步：用 WordPress 自带的修复工具
这是门槛最低的办法。编辑 wp-config.php，在 /* That's all, stop editing! */ 这一行之前加一句：
define('WP_ALLOW_REPAIR', true);然后浏览器访问 https://你的域名/wp-admin/maint/repair.php。这个页面不需要登录，所以修完必须立刻把那行删掉，否则等于给外人开了个后门。页面上有两个按钮，先点 “Repair Database”，不行再点 “Repair and Optimize Database”。
要提醒的是，这个工具底层调的就是 MySQL 的 REPAIR TABLE，而 REPAIR TABLE 只对 MyISAM 引擎有效。现在大部分站点的表都是 InnoDB，点了很可能提示 “The storage engine for the table doesn’t support repair”。别慌，往下走。
第三步：命令行修 MyISAM
如果确认是 MyISAM，命令行更快也更可控：
mysqlcheck -u root -p --auto-repair --check --optimize 数据库名想只修某一张表：
mysql -u root -p 数据库名 -e "REPAIR TABLE wp_options;"常出问题的是 wp_options 和 wp_postmeta，前者因为 autoload 数据频繁读写，后者是因为数据量大。修完记得跑一次 CHECK TABLE 复查状态是不是 OK。
第四步：InnoDB 损坏的处理方式
InnoDB 不能直接 REPAIR，思路是”强制启动 → 导出 → 重建”。先做一份文件级备份，把 /var/lib/mysql 整个目录 cp 一份出去，这一步千万别省。
然后在 /etc/mysql/my.cnf 的 [mysqld] 段加上：
innodb_force_recovery = 1重启 MySQL。如果起不来，把值改成 2、3 逐级往上试。数字越大限制越多，超过 4 会有丢数据的风险，能起来就赶紧停手。服务起来之后立刻导出：
mysqldump -u root -p --single-transaction 数据库名 > /root/rescue.sql导完把 innodb_force_recovery 那行注释掉，重建一个空库再导回去：
mysql -u root -p -e "CREATE DATABASE wp_new DEFAULT CHARSET utf8mb4;"
mysql -u root -p wp_new < /root/rescue.sql最后改 wp-config.php 里的 DB_NAME 指向新库。注意在 recovery 模式下 MySQL 是只读的，写操作会报错，所以别在这个阶段让站点对外提供服务。
第五步：让它不再发生
修好只是止血。真正省事的是这几件事：给 mysqldump 配个 cron，每天凌晨备份一次并保留 7 天；给磁盘用量加个告警，超过 85% 就通知；服务器关机用 shutdown -h now 而不是直接拔电；如果还有 MyISAM 的表，找个低峰期用 ALTER TABLE 表名 ENGINE=InnoDB; 转过去，InnoDB 有事务日志，抗崩溃能力完全不是一个量级。
常见问题
问：repair.php 页面提示 404 或者打不开怎么办？
先确认 WP_ALLOW_REPAIR 那行确实写在了 wp-config.php 里、而且没写在文件末尾的 require_once 之后。有些安全插件会拦截 /wp-admin/maint/ 路径，临时把插件目录改名再试。
问：修完之后文章内容变成乱码了？
这通常不是损坏造成的，是导入导出时字符集不一致。导出加上 --default-character-set=utf8mb4，建库时也指定 utf8mb4，再重新导一次。
问：能不能直接从 phpMyAdmin 修？
可以。勾选表之后底部下拉框选 “修复表”，效果和 REPAIR TABLE 一样，同样只对 MyISAM 生效。表比较大的时候浏览器容易超时，还是命令行稳。
你在修数据库时踩过什么坑，或者卡在 InnoDB 恢复的哪一步了，欢迎在 fenij.com 留言说说具体报错，我看到会回。
