打开网站直接白屏，只甩一句 “Error establishing a database connection”，先别急着重装。九成情况下根因就两类：要么是 wp-config.php 里的数据库名、用户名、密码写错，要么就是数据库服务本身没起来。下面这套排查顺序照着走，基本十分钟能定位。
一、先确认是不是真的连不上库
白屏不一定都是数据库的问题，插件冲突、内存耗尽也会白屏。先到后台 /wp-admin/ 看一眼：如果连登录页都进不去、满屏都是 “database connection”，那才真是数据库连接失败。如果后台能进、只是前台某页报错，多半是别的毛病，别在这上面浪费时间。
二、核对 wp-config.php 四个常量
最常见的就是迁移服务器后凭据对不上。用下面这条直接把四个关键常量打出来：
grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" wp-config.php逐个核对：DB_NAME 是库名、DB_USER 是数据库用户名、DB_PASSWORD 是密码、DB_HOST 多数情况填 localhost（用 Unix socket 连接），云数据库一般给的是内网地址如 10.0.0.x:3306。把这几个值跟主机面板里的数据库信息一字不差对一遍，大小写、下划线、端口都别漏。
| 现象 | 最可能的原因 | 第一动作 |
|---|---|---|
| Access denied for user | 用户名或密码错 | 改 DB_PASSWORD 重填 |
| Unknown database ‘xxx’ | DB_NAME 指向的库不存在 | 先建库或导入备份 |
| 连接超时 / 拒绝 | DB_HOST 填错或服务没起 | 查 DB_HOST 与服务状态 |
三、数据库服务本身挂了
凭据全对还连不上，多半是 MySQL/MariaDB 进程没跑。先看状态：
systemctl status mariadb
# 或
service mysql status如果服务是 inactive (dead)，直接 systemctl start mariadb 拉起来。云服务器偶尔会因为内存爆掉（OOM）被系统杀掉，起来后又被压垮，这种要先解决内存问题，否则拉起来也没用。
四、表损坏：用 WP_ALLOW_REPAIR 修
如果提示 “One or more database tables are unavailable”，说明表坏了。在 wp-config.php 里加一行：
define('WP_ALLOW_REPAIR', true);然后浏览器访问 /wp-admin/maint/repair.php，点“修复并优化数据库”。修完这行一定要删掉，否则任何人都能进这个页面。盘符/权限问题导致修复失败的，先用 mysql -u root -p -e "SHOW DATABASES;" 确认能登进去再说。
踩坑实录
一次迁移后我把新服务器的数据库密码改了，wp-config.php 也跟着改，结果还是报 “Access denied for user”。我以为密码没改对，翻来覆去重置了三遍，越改越乱。最后用 mysql -u wpuser -p -h 127.0.0.1 一试，提示的却是 “Unknown database ‘wpdb’”。原来迁移时我只导了表、没建库，DB_NAME 指向的库根本不存在。教训：看到 Access denied 别光盯密码，先 SHOW DATABASES 确认库在不在，库名错和口令错长得很像，但修法完全不同。
常见问题
Q：localhost 和 127.0.0.1 填哪个？
A：填 localhost 走 Unix socket，通常更快也更稳；只有当主机明确要求 TCP 连接、或 socket 文件路径异常时才填 127.0.0.1。两个换来换去没解决过问题的话，基本就不是这里的事。
Q：修复页面打不开怎么办？
A：多半是 WP_ALLOW_REPAIR 没加对位置、或文件权限让 WordPress 读不到。确认常量加在 /* That's all, stop editing! */ 之前，再用 mysql 客户端直连手动 REPAIR TABLE 也行。
Q：服务一重启又被杀？
A：大概率是内存不够触发 OOM。先看 journalctl -k | grep -i "out of memory"，堆内存或换大实例才是根治，单纯重启是在和内核抢资源。
数据库这摊事，平时做好自动备份最省心。如果你在运维 WordPress 上还有拿不准的坑，欢迎到 fenij.com 留言一起交流。
