简介：围绕“建立数据库连接时出错”这一常见故障，梳理 MyISAM 表损坏的定位方法、只读排查路径、修复流程，以及小内存服务器下 MySQL 被反复终止的根因分析与配置优化。读者可借此形成一套从应急修复到长期稳定的处理思路，减少同类问题反复出现。
WordPress 站点突然无法访问，页面持续提示“建立数据库连接时出错”。该问题并非首次出现，在服务器迁移后已经多次发生。此前虽然做过修复，但始终没有定位到根因，导致故障反复。
这一次没有继续采用临时修复的思路，而是先让自动化排查工具以只读方式接入数据库，按照“先确认状态、再定位损坏、最后修复”的流程处理。排查过程中没有直接重启服务，也没有贸然修改表数据，而是先通过系统视图和文件状态判断数据库到底哪里出了问题。
这类故障的典型表现是网站能解析、Web 服务能响应，但应用层无法获取数据库连接。原因不一定只是密码错误或服务未启动，更常见的是数据库服务异常退出、表损坏、连接数耗尽或内存不足。对 WordPress 来说，如果数据库可以连接但关键表不可读，同样会表现为数据库连接错误。
排查的第一步是确认数据库当前使用的表引擎。WordPress 默认常用 MyISAM 或 InnoDB，不同引擎在异常关闭后的表现差异很大。InnoDB 通常依靠重做日志进行崩溃恢复，而 MyISAM 不具备完整的事务恢复能力，一旦写入过程中进程被强制终止，索引文件和数据文件之间很容易出现不一致。
通过查询 information_schema 时发现，wp_options 表返回结果为空。这个现象非常关键。wp_options 是 WordPress 存放全局配置、站点地址、主题选项和插件设置的核心表，如果它无法读取，站点的初始化流程会直接失败，前端就会表现为数据库连接错误。
对于 MyISAM 表来说，查询返回空值但数据库又能正常连接，通常不是 SQL 语句问题，而是表已经处于损坏状态。MyISAM 表由三部分组成：
.frm：表结构定义文件.MYD：数据文件.MYI：索引文件只要索引文件丢失或损坏，MySQL 就可能无法通过索引定位数据，甚至在查询时直接判定表不可用。
接着检查磁盘上的表文件。数据文件 wp_options.MYD 仍然存在，大小约 1.4MB，说明数据本身基本完整。但索引文件 .MYI 已经很长时间没有更新。文件时间戳停留在崩溃发生的时间点，之后虽然服务可能被反复拉起，但该表一直处于 crashed 状态，没有被真正修复。
这意味着此前手动恢复可能只是让 MySQL 暂时启动成功，并没有彻底修复表结构或索引。一旦应用再次频繁访问这张表，问题会重新暴露。
修复前先完成备份。备份操作不能只复制单个文件，而是将整个表相关文件打包到独立目录。备份完成后再执行修复操作。这样做的好处是，即使修复过程中出现更严重的损坏，也可以回滚到当前状态重新处理。
修复语句使用 MyISAM 表支持的常规命令：
REPAIR TABLE wp_options;
执行后返回状态为 OK，说明表和索引已经恢复。此时再次查询 wp_options，数据能够正常返回。修复完成后没有立即结束，而是继续检查是否还有其他表存在类似问题，避免只修复单点后很快再次失败。
在 WordPress 场景中，除了 wp_options，还经常需要关注：
wp_posts：文章和页面内容wp_postmeta：文章元信息wp_term_relationships：分类与文章关系wp_usermeta：用户元信息如果这些表中有 MyISAM 引擎且服务器曾多次异常断电或强制终止进程，也可能存在潜在损坏风险。批量检查方式可以通过 information_schema 查询表引擎，再结合 CHECK TABLE 做快速检测。
表修复只是解决了当前不可用的问题，但并没有解释为什么表会反复损坏。如果只停留在这一层，未来故障仍会周期性地出现。
继续排查发现，这台服务器内存只有 2GB，但 MySQL 的 max_connections 设置为 500。对 WordPress 来说，500 个并发连接并不是必须的。大多数中小站点实际同时活跃的数据库连接远小于这个数量。连接数设置过高，意味着 MySQL 会为潜在连接预留更多内存缓冲区，在高负载时更容易触发系统内存不足。
Linux 系统在内存耗尽时会触发 OOM Killer，选择内存占用较高的进程强制终止。MySQL 通常是首选目标之一。MyISAM 表在被强制终止时没有机会完成文件同步和索引刷新，下一次启动时就会留下 crashed 标记。这个循环一旦形成，每次手动修复都只是清理了结果，没有切断原因。
此前多次修复没有根治问题，正是因为服务器配置与实际资源不匹配。数据库服务不断被系统杀死，表损坏成为必然结果。
确定根因后，调整方向很清晰：降低 MySQL 的内存占用，使其在 2GB 内存环境下稳定运行，同时给系统留下足够余量，避免进入 OOM 状态。
将 max_connections 从 500 调整为 100。对普通 WordPress 站点来说，100 个并发连接已经足够。即便瞬时请求较高，也可以通过连接复用和前端缓存缓解压力，而不是无限增加数据库连接。
max_connections = 100
performance_schema 在排查性能问题时很有用，但会持续占用内存。如果日常并不依赖它做实时分析，可以在小内存服务器上关闭：
performance_schema = OFF
key_buffer_size 是 MyISAM 索引缓存的核心参数。原配置为 32M，在小内存机器上偏高。将其调整为 16M，降低常驻内存占用：
key_buffer_size = 16M
虽然本次损坏集中在 MyISAM，但 innodb_buffer_pool_size 也不能忽略。对于 2GB 内存服务器，InnoDB 缓冲池不宜设置得过大，否则同样会挤压系统可用内存。一般建议为该参数预留内存不超过总内存的四分之一到三分之一，具体取决于站点的 InnoDB 使用量。
完成上述调整后重启 MySQL，内存占用从约 287MB 降至 62MB，降幅约 78%。这个结果说明原配置中确实存在大量无效或预分配内存。
降低 MySQL 内存占用后，还需要考虑系统级兜底策略。单纯依赖物理内存很难应对突发流量或后台任务集中执行造成的瞬时峰值。为此，将 Swap 从 1GB 扩展至 2GB。
Swap 并不是解决内存不足的根本手段，但可以防止系统在短暂压力下直接触发 OOM。对数据库服务来说，有少量 Swap 作为缓冲，比直接被杀死更安全。
修改 Swap 配置时，需要同步更新系统挂载文件，使服务器重启后配置仍然生效。这样既避免了临时扩容在重启后失效，也让运行环境具备可持续性。
需要注意，Swap 设置过大可能导致系统在高负载时频繁交换，影响响应速度。对于数据库服务器，一般根据物理内存和业务负载综合判断。2GB 物理内存下，2GB Swap 属于相对稳妥的范围，重点用于应急缓冲，而非长期承载主要内存压力。
修复和配置调整完成后，进行了多维度验证：
crashed 记录。wp_options 表查询正常，站点配置读取无误。修复动作本身并不复杂，复杂的是能否把“表损坏”和“内存不足导致进程被杀”串成完整链路。寻找根因比重复修复更有价值。只有找到触发条件并调整运行配置，才能避免同类问题反复出现。
对运维人员或站长来说，建议在小内存服务器上持续关注数据库内存占用、Swap 使用率以及系统日志中的 OOM 记录。如果条件允许，可以将数据库相关监控纳入巡检流程，提前发现连接数、缓存命中率、表状态和进程退出等异常信号。