WordPress 数据库崩溃修复记录

文章目录

官网 WordPress 站今天又打不开了，页面仍然提示 建立数据库连接时出错。这个报错其实从搬服务器以后就一直出现，第一次尝试修复的时候没有找到根本原因，干脆就放在那里摆烂了。

这次所有的服务器大整顿，正好宝塔又支持 AI，直接让 AI 上阵做只读排查。

把问题给 AI 描述完，它用 root 连上数据库，先确认表引擎。查 information_schema 时发现 wp_options 返回全是空值，分析出 MyISAM 表严重损坏的典型信号，多半是索引文件 .MYI 或数据文件 .MYD 丢了或坏了。

然后它自动检查磁盘上的表文件，wp_options.MYD 有 1.4MB，数据是好的。但 .MYI 索引文件从 10 月 1 日 12 点之后就没再更新过，表在那个时候就崩了，之后一直标记成 crashed，没真正修复过。难怪连不上。

中途 AI 也完全没有让我插手。它自动先将表文件备份到 /www/backup/wp_options_repair_20261102/。完成后执行了 REPAIR TABLE wp_options，检查返回状态 OK，确保所有数据都回来了。又进入下一步。

做完这些，它还没忘最终任务是解决 建立数据库连接时出错 反复出现的问题。它发现服务跑在一台 2GB 内存的小破机器上，MySQL 配置却很激进，max_connections 开到 500（其实是因为搬服务器之前，咱公司还是挺有实力的，也曾有过很强的服务器，咱也曾被人看好过。这个故事可以留着以后讲 😮‍💨）。内存被吃光后 OOM killer 把 MySQL 干掉，MyISAM 表异常关闭就损坏。然后每次我手动修好后，这个循环再来一遍，所以就一直在崩，因为我确实没有找到根本问题。

所以 AI 分析完以后，为了防复发，考虑直接降内存压力。改 /etc/my.cnf，max_connections 从 500 降到 100，关掉 performance_schema，key_buffer_size 从 32M 降到 16M，重启 MySQL。从它输出日志来看，内存占用从 287MB 降到 62MB，降了 78%。

调整的最后一步，它认为光降配置还是吃劲，于是把 Swap 从 1GB 扩到 2GB，写进 fstab 让重启后自动挂载。这样让内存再紧张也有缓冲。

最后它自己验证，站点返回 200，响应 0.57 秒，日志里没有新的 crashed 错误。

这次修复完完全全是 AI 主导，非常完美。其实用的模型很基础，是 sensenova-6.8-flash，主要其实还是靠宝塔面板强大的 MCP，让 AI 可以直接操作数据库和服务器，排查问题。真是一场酣畅淋漓又轻松无比的修复体验。

AI 推荐接下来再观察几天，如果问题不再复发，就把 wp_options、wp_posts、wp_postmeta 这些核心表转成 InnoDB。

先这样，收工。