WordPress 显示 Error establishing a database connection 怎么办？配置、服务与连接排查

先确认数据库“还在不在”，不要先重装 WordPress：看到 Error establishing a database connection，表示 WordPress 当前无法用 wp-config.php 里的数据库名、用户、密码和主机连接 MySQL。先进入宝塔面板的“数据库”查看目标数据库是否存在，再到“软件商店 → 已安装 → MySQL”确认服务状态；使用独立数据库时，则到对应云数据库控制台查看实例运行状态。只读检查通常不额外收费，云数据库升配、备份空间和新磁盘可能收费。

修改连接信息本身不会删除文章和订单，但填错会让全站继续离线。数据库修复、还原备份、删除表或重置用户权限会改变数据。操作前备份 wp-config.php，并确认有可恢复的数据库备份；不要把“重装 WordPress”“清空数据库”或“删除 wp-content”当作第一步。

先判断是持续报错还是偶发报错

持续报错通常来自凭据、数据库主机、服务停止或网络路径错误。刷新后偶尔恢复，更像连接数耗尽、MySQL 重启、磁盘满、内存不足或数据库网络抖动。先记录报错时间、受影响域名、前台与后台是否同时失败，再按同一时间查看 PHP 和 MySQL 日志。不要靠连续刷新覆盖故障现场。

现场	优先检查	不要先做
迁移、改密码后持续报错	DB_NAME、DB_USER、DB_PASSWORD、DB_HOST	重复恢复旧数据库
高峰期偶发，刷新恢复	连接上限、慢查询、重试、MySQL 重启	无限调大连接数
服务器重启后出现	MySQL 是否启动、磁盘与挂载是否正常	删除数据库文件
只有一个站点失败	该站点配置、用户授权、数据库名	重启整台服务器

怎样安全核对 wp-config.php

在宝塔“网站 → 目标站点 → 根目录”找到 wp-config.php。先下载备份，再核对四个字段。不要把数据库密码粘贴到聊天、截图或工单。通过 SSH 检查时，下面的命令只显示数据库名、用户和主机，故意不读取密码；请把路径替换为真实站点目录。

cd /www/wwwroot/你的站点目录
grep -E "DB_(NAME|USER|HOST)" wp-config.php

输出应与宝塔数据库条目或云数据库连接信息一致。DB_HOST 不一定是 localhost：远程数据库通常是内网地址或域名，非默认端口可能写成 主机:端口。迁移时只改了数据库名、没有同步用户授权，或者恢复了旧版 wp-config.php，都会造成相同报错。

从服务器直接测试数据库连接

先确认 MySQL 服务和端口。不同发行版服务名可能是 mysql 或 mariadb，宝塔自编译环境也可能不由系统服务管理。下面命令只读状态，不会修改数据库。

sudo systemctl status mysql --no-pager
sudo ss -lntp | grep 3306
mysqladmin ping -h 数据库主机 -P 数据库端口 -u 站点数据库用户 -p

mysqld is alive 说明服务可达且认证路径能够响应。Access denied 表示网络已通，应核对用户名、密码、来源主机和授权；Connection refused 通常是服务未监听或地址、端口错误；超时则继续检查云安全组、主机防火墙、私网路由和数据库白名单。测试远程数据库时不要为了省事把 3306 永久开放给全网。

数据库服务停了，应该查什么

先看状态和故障时段日志，再决定是否启动。直接反复重启可能覆盖线索，也可能让损坏恢复循环持续发生。

sudo journalctl -u mysql --since "30 minutes ago" --no-pager
df -hT
df -i
free -h

磁盘或 inode 满时，先按文件用途清理或扩容，禁止直接删除 MySQL 数据目录。日志出现 OOM、InnoDB、只读文件系统或 I/O 错误时，应先保护数据并处理底层问题。只有确认配置与存储正常后再启动服务，并观察是否稳定运行，而不是以一次 active 状态作为完成。

偶发错误要检查连接耗尽和重启

如果管理员还能连接，在新会话读取运行时间、当前连接和历史峰值。执行前把“管理用户”替换成有只读状态权限的账号。

SHOW GLOBAL STATUS LIKE 'Uptime';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW VARIABLES LIKE 'max_connections';
SHOW FULL PROCESSLIST;

Uptime 突然很小，说明 MySQL 最近重启；连接逼近上限时，应查连接池、慢查询和异常重试。大量 Sleep 不能单独证明泄漏，要结合持续时间和应用池设置判断。先降低异常请求和重试，再处理根因；盲目增加 max_connections 可能让内存压力更严重。具体连接耗尽处理可继续查看MySQL Too many connections 排查。

什么时候才需要数据库修复

“无法连接”不等于“数据表损坏”。只有 MySQL 已可连接，而且日志或后台明确指出表损坏时，才评估修复。WordPress 的 WP_ALLOW_REPAIR 会开放一个无需登录的修复入口；如果确需使用，应先备份数据库，只在维护窗口短时开启，完成后立即从 wp-config.php 删除该常量。不要在数据库服务未运行、磁盘只读或凭据错误时尝试修复。

修复后怎样验收和回退

1. 在未登录窗口打开首页、文章页与 /wp-admin/，确认不再出现连接错误。
2. 执行一次低风险写入，例如在测试内容中保存草稿；有商城时检查商品、购物车和订单后台，但不要制造真实付款。
3. 连续观察 PHP、WordPress 和 MySQL 日志，确认没有新的拒绝连接、重启或磁盘错误。
4. 重启受影响的 PHP 进程或应用连接池后再测，排除旧连接暂时掩盖问题。
5. 确认备份任务、定时任务和监控恢复，再结束维护。

如果新凭据或新数据库地址无效，立即恢复备份的 wp-config.php，不要继续随机改密码。若数据恢复后内容缺失，停止新的写入，保留当前库和恢复库，按时间点与表前缀核对后再切换。磁盘已满时先参考Linux 磁盘满排查；若页面变成 PHP 致命错误，则按WordPress 致命错误恢复取证，不要混成同一个故障。

官方资料

• WordPress：常见错误中的数据库连接故障
• WordPress：编辑 wp-config.php
• WordPress：数据库连接常量与 DB_HOST

以上资料于 2026 年 9 月 3 日核验。界面和托管环境可能变化，数据库地址、端口与费用以当前面板和服务商页面为准。