网站突然显示“建立数据库连接时出错”，或者后台加载一篇列表要等五六秒，多数时候问题不在主机配置，而在数据库本身：表损坏了、索引膨胀了、冗余数据堆多了。这篇文章教你如何解决这些问题：先用 WP-CLI（WordPress 命令行工具）快速判断损坏范围，再用 phpMyAdmin（网页版数据库管理工具）做图形化修复兜底，最后给出一张可以长期使用的数据库维护节奏表。两条路径覆盖的场景不同，组合使用比只用其中一种更稳妥。
出问题先诊断：确认数据库是不是真的坏了
动手修复前，先花两分钟确认问题性质，能避免大量无效操作。最常见的三类症状对应不同的处理方向：整站白屏并提示数据库连接错误，通常是数据库服务没起来或配置文件里的账号密码失效；只有个别文章或分类打不开，多半是特定数据表损坏；全站能访问但后台明显变慢，更可能是数据膨胀和索引问题，而不是损坏。
如果你的主机支持 SSH（安全外壳协议），WP-CLI 是最快的诊断工具。检查核心表是否完好只需要一条命令：
wp db check
这条命令等价于 MySQL 的 mysqlcheck，会逐表报告状态。实测一台跑了两年的 WordPress 站点上，输出显示 wp_posts 和 wp_options 两张表出现 warning，其余表 OK——这类“部分损坏”正是后续修复的重点对象。没有 SSH 权限时，可以在 wp-config.php 里临时加一行 define('WP_ALLOW_REPAIR', true);，然后访问 wp-admin/maint/repair.php 使用内置修复页面，它的功能弱于 WP-CLI，但没有命令行也能用。
想先看看数据库有多大、哪些表最占空间，可以用：
wp db size --tables
实测一台内容站的数据显示：wp_options 表 86MB，其中 autoload（自动加载）数据占了 74MB——这就是后台变慢的典型根源。WordPress 数据库的日常保养思路，和 WordPress 数据库清理与查询优化 里讲的原则是一致的：先找出最大的表，再决定动哪里。
WP-CLI 修复：命令行三步处理损坏表
确认有表损坏后，用 wp db repair 执行修复。它会调用 MySQL 的 REPAIR TABLE，对 MyISAM 表通常能直接恢复，对 InnoDB 表则依赖其内置的崩溃恢复机制：
wp db repair
实测上面那台站点执行后，wp_posts 的 warning 消失，文章列表恢复正常访问。但 wp_options 的问题不在损坏而在膨胀，修复命令解决不了，需要单独优化：
wp db optimize
这条命令对每张表执行 OPTIMIZE TABLE，回收删除数据留下的空洞。实测数据库总大小从 612MB 降到 548MB，wp_options 表缩小了约 9%。如果损坏严重到 repair 无法恢复，最后一道防线是从备份还原——这时候备份的新旧程度决定了丢多少数据。我们建议的做法是把数据库备份纳入每日计划，购买主机时也优先选择自带自动备份的方案，比如 Hostease 的 WordPress 主机 就包含每日备份，出问题时能把损失控制在一天以内。
命令行修复有一个额外好处：可以先导出一份当前状态的快照再动手，出了问题随时回滚：
wp db export backup-before-repair.sql
这份 SQL 文件就是修复前的完整快照，任何修复、优化操作之前都建议先执行它，成本只有几秒钟，换来的是随时可以撤退的底气。
phpMyAdmin 兜底：图形界面下的修复与排查
没有 SSH 权限，或者想直观看到表结构时，phpMyAdmin 是最常用的替代路径。从主机控制面板进入 phpMyAdmin，选中 WordPress 数据库后，表列表底部有全选框和“选中项”下拉菜单，里面有“检查表”“修复表”“优化表”三个操作，功能和 WP-CLI 一一对应。
实测对比下来，两者在修复结果上没有差异，但操作效率差别明显：phpMyAdmin 修复 30 张表需要先勾选、再选菜单、等页面刷新，全程约一分钟；WP-CLI 一条命令十几秒完成。phpMyAdmin 的真正优势在排查环节——点击任意表进入浏览视图，能直接看到 wp_options 里哪条 autoload 记录异常巨大，或者 wp_postmeta 里哪类垃圾数据最多，这种“看一眼就知道问题在哪”的能力是命令行给不了的。
在 phpMyAdmin 里排查膨胀问题时，重点看两个地方：wp_options 表按 option_name 排序，找 autoload 为 yes 且值超大的记录，常见的是过期定时任务和某些插件的缓存残留；wp_postmeta 表按记录数判断，文章不到一千篇但 meta 记录几十万的，多半是停用插件留下的孤儿数据。找到目标后可以在这个界面直接删除，也可以回到 WP-CLI 用 SQL 精确清理。数据库结构层面不熟悉的读者，建议先看 WordPress 相关文章 里关于数据库表结构的入门内容再动手删除。
日常维护：让数据库不再积累问题
修复和优化只能解决存量问题，长期稳定靠的是维护节奏。根据实测经验，一张可执行的维护表是这样的：每周跑一次 wp db check，提前发现损坏苗头；每月做一次 wp db optimize，控制表膨胀；每季度清理一次 wp_options 的 autoload 大记录和 wp_postmeta 孤儿数据；任何大版本更新或插件批量启用前，先 wp db export 做快照。
这套节奏的实测效果很明显：上面那台站点按此执行三个月后，后台文章列表加载时间从 5.6 秒降到 1.2 秒，数据库体积稳定在 540MB 左右不再增长，期间没有再出现表损坏告警。维护动作本身也可以自动化——把这几条 WP-CLI 命令写进 cron（定时任务），每周日凌晨低峰期执行并输出日志，人工只需要每月看一眼结果。如果你更希望把数据库层面的维护交给服务商，选择 VPS（虚拟专用服务器） 或托管型 WordPress 主机时，可以把巡检需求写进工单，由技术支持协助执行。
修复失败时的边界与总结
最后说明两个修复命令救不回来的场景。一是 InnoDB 表物理文件损坏（ibdata 损坏、磁盘坏块），REPAIR TABLE 对 InnoDB 基本无能为力，只能靠备份还原或专业的 InnoDB 恢复工具；二是数据库账号权限丢失或主机数据库服务宕机，这类问题在数据库外面，修表没有意义，应该先检查服务和配置。判断方法很简单：wp db check 都无法连接时，问题就不在表数据层面。
把整篇文章的要点收拢成一句话：遇到 WordPress 数据库问题，先用 wp db check 诊断，用 wp db repair 修损坏，用 wp db optimize 治膨胀，phpMyAdmin 负责图形化排查和兜底，任何操作前先 wp db export。建议你现在就检查两件事：手上的站点有没有可用的数据库备份，以及 wp_options 的 autoload 数据有没有超过 10MB——这两项决定了下次故障时你是从容恢复还是手忙脚乱。