先把错误含义拆开
WordPress 站点出现“Error establishing a database connection”时，很多人第一反应是服务器坏了，或者 MySQL 服务挂了。实际上，这句话只说明一件事：WordPress 在当前请求里没有成功连接到数据库。至于是数据库进程没启动、账号密码不对、权限不足、连接数打满，还是网络和磁盘问题导致数据库不可用，都需要继续拆开看。
排查这类故障，最忌讳一上来就重装插件、换主题、反复覆盖程序文件。WordPress 的文章、页面、用户、设置大多存在数据库里，如果没有先确认备份和数据库状态，盲目操作反而可能扩大故障。更稳妥的思路是：先判断影响范围，再看连接配置，再查数据库服务，最后才进入应用层和资源层。
先判断影响范围
第一步不是登录后台，而是确认前台、后台、静态资源和数据库管理工具的表现是否一致。如果前台和后台都报数据库连接错误，但图片、CSS、JS 这类静态资源还能直接访问，说明 Web 服务大概率还活着，问题集中在 PHP 到数据库这一段。如果只有后台慢或报错，前台多数页面正常，则可能是后台插件、缓存刷新、定时任务或某些管理接口在拖慢数据库。
还要看故障是持续存在，还是偶发出现。持续报错通常更像数据库服务停止、配置变更、密码错误、磁盘满、权限问题；偶发报错则更像连接数耗尽、慢查询堆积、瞬时流量冲击、备份任务占用资源，或者服务器负载在某个时间段突然升高。这个判断会直接影响后面的排查方向。
检查 wp-config.php 配置
WordPress 连接数据库主要依赖 wp-config.php 里的四项：DB_NAME、DB_USER、DB_PASSWORD 和 DB_HOST。如果近期做过搬家、改密码、切换数据库实例、恢复备份或调整面板配置，这里就应该优先核对。常见问题包括数据库名写错、用户名写错、密码含特殊字符但复制不完整、主机从 localhost 改成了内网地址却没同步更新。
需要注意，DB_HOST 不一定永远是 localhost。有些环境使用本机 MySQL，有些使用独立数据库服务器，有些面板会使用 127.0.0.1、内网 IP、端口写法，甚至 Unix Socket。迁移网站时，如果只复制了 WordPress 文件，没有同步数据库连接信息，页面就很容易直接报错。
确认数据库服务还在运行
如果配置没有变化，就要确认 MySQL 或 MariaDB 服务是否正常运行。在 Linux 服务器上，一般可以查看服务状态、端口监听和错误日志。例如使用 systemctl status mysql、systemctl status mariadb、ss -lntp、journalctl -u mysql 等方式，观察服务是否启动、是否反复崩溃、是否因为权限或磁盘问题无法写入。
如果数据库服务没有启动，不要只执行重启命令就结束。重启成功只是恢复访问，真正原因还要继续看日志。比如 InnoDB 文件损坏、磁盘空间不足、内存不够被 OOM 杀掉、配置参数写错、数据目录权限异常，都可能导致数据库无法稳定运行。把这些原因找出来，才算真正闭环。
用命令验证账号权限
当服务正常运行时，可以直接用 WordPress 配置里的账号尝试连接数据库。示例命令类似：mysql -u 数据库用户名 -p -h 数据库主机 数据库名。如果命令行也连不上，说明问题不在 WordPress，而在账号、密码、授权、网络或数据库本身。如果命令行能连上，但 WordPress 仍报错，再回头看 PHP 扩展、运行环境和应用层配置。
账号权限也是常见坑。数据库用户不只需要能登录，还需要对对应数据库拥有读取、写入、建表、修改等权限。某些搬家场景里，数据库导入了，用户也创建了，但没有正确授权；或者授权只允许从 localhost 访问，而实际 Web 服务连接来源变成了另一个内网地址。这时错误表面上像密码不对，本质上是访问来源或权限不匹配。
别忽略连接数和慢查询
如果报错是偶发的，尤其是高峰期才出现，就要重点看连接数。WordPress 站点在插件较多、缓存配置不合理、爬虫访问频繁时，可能短时间打开大量数据库连接。当 MySQL 的最大连接数被占满，新请求就会连接失败，前台可能间歇性出现数据库连接错误。
这时可以查看当前连接、慢查询日志和 Web 访问日志，判断是否有异常 IP、搜索爬虫、后台接口或某个插件制造了大量请求。处理办法不一定是立刻把 max_connections 调得很大。连接数上限提高只是缓解症状，如果慢 SQL、无缓存页面、恶意扫描和后台任务不处理，数据库还是会再次被拖垮。
磁盘、内存和权限也会导致数据库不可用
数据库连接失败不一定是“连接信息”问题。磁盘满了，MySQL 可能无法写临时文件、binlog 或表数据；inode 用完了，也可能明明还有空间却创建不了新文件；内存不足时，数据库进程可能被系统杀掉；数据目录权限错了，服务也可能启动失败。这些都可能最终表现为 WordPress 连不上数据库。
所以排查时要同时看 df -h、df -i、free -h、dmesg、数据库错误日志和系统日志。不要只盯 WordPress 报错页面。很多线上故障的根因其实藏在系统层，只是最后由应用页面展示出来。
恢复前先做备份
如果故障涉及数据库修复、表修复、恢复备份、删除日志、调整数据目录或修改权限，动手前最好先做一次当前状态备份。即使数据库已经异常，也应该尽量保留数据目录、配置文件和日志。这样后续排查误操作时还有回退空间。
小站点可以用控制面板或命令行导出数据库；业务更重要的站点，则应有定期快照、异地备份和恢复演练。只备份文件不备份数据库，对 WordPress 来说远远不够，因为最关键的文章内容和站点设置都在数据库里。
不同部署场景的处理重点
如果 WordPress 和数据库在同一台服务器上，重点看本机服务、磁盘、内存、权限和本地连接。如果数据库是单独实例或云数据库，除了账号密码，还要看安全组、白名单、内网地址、端口开放、实例状态和云厂商控制台告警。如果站点前面还有 CDN 或反向代理，则要区分用户看到的是缓存页面、源站错误，还是代理层返回的错误。
对于没有专职运维的小团队，建议把网站程序、数据库、备份和监控放在同一套可管理的基础设施里。比如使用 速维云云服务器 部署 WordPress 时，可以结合资源监控、快照备份和线路选择，把数据库故障从“完全靠猜”变成“有日志、有监控、有回退”。如果面向海外访问，再根据业务地区选择香港、日本或美国线路，会比单纯提高配置更有效。
一套实用排查顺序
遇到 WordPress 数据库连接失败，可以按这个顺序处理：先确认前后台是否都异常；再核对 wp-config.php；然后检查 MySQL 或 MariaDB 服务状态；接着用命令行验证账号能否连接；再看数据库连接数、慢查询、访问日志和资源使用；最后检查磁盘、inode、内存、权限和备份恢复情况。
这套流程的好处是不会把所有问题都归咎于 WordPress，也不会一上来就做高风险操作。数据库连接失败只是表象，真正的排障目标是把“连不上”拆成配置、服务、权限、资源、流量和环境几个层面逐一验证。这样处理，恢复速度更快，也更不容易在慌乱中把小故障修成大事故。
