网站建立数据库连接时出错

凌晨两点，网站手机弹出一条推送：站点宕机。建立接我点开监控面板，数据错误日志里清一色写着——"建立数据库连接时出错"。库连这个提示太熟了，出错熟到让人想砸键盘。网站它不是建立接那种会告诉你具体哪行代码崩了的错误，它像个哑巴保安，数据拦在门口，库连什么也不说，出错就让你干瞪眼。网站

很多人第一次碰到这个报错，建立接是数据在WordPress后台。页面白屏，库连顶部一行小字，出错底下什么都没有。你刷新，还是它。你重启服务器，还是它。你甚至开始怀疑是不是机房拔了网线。其实问题往往没那么宏大。

我处理过的案例里，最常见的是数据库凭据变了。比如有人改了MySQL密码，但忘了同步更新wp-config.php里的DB_PASSWORD。文件里那串字符还是旧的，数据库那头已经翻脸不认人。连接自然被拒。这种情况有个很笨但有效的排查方式：拿同样的用户名密码，在命令行里mysql -u user -p试一下。如果命令行也进不去，那就不用折腾网站了，先解决账号问题。

另一种情况更隐蔽——数据库服务根本没起来。MySQL进程挂了，或者被系统OOM killer干掉了。服务器内存不够的时候，Linux会挑最占内存的进程下手，MySQL经常中枪。你去看/var/log/mysql/error.log，大概率能看到"Out of memory"或者"Killed process"的字样。这时候重启MySQL能暂时恢复，但如果不加swap或者不优化查询，过几天还会再来一次。

还有一类问题出在连接数上。MySQL默认max_connections是151。听起来不少，但如果你的站点用了持久连接，或者某个插件疯狂开新连接不释放，很快就会打满。打满之后，新的连接请求全部被拒，网站就报这个错。我见过一个电商站，装了个促销插件，每次页面加载开三个数据库连接，大促当天直接炸了。查SHOW PROCESSLIST，一堆Sleep状态的连接堆在那里，像堵在高速路口的车。

主机商那边的问题也不能忽略。共享主机上，数据库服务器和Web服务器经常不是同一台。如果两台机器之间的内网抖了一下，或者防火墙规则更新了，连接就会超时。这种你本地怎么查都没用，只能开工单。我有次帮人排查，折腾了四十分钟，最后主机商回复说"数据库节点正在迁移"。你除了等，什么也做不了。

说回开头那个凌晨。我登进服务器，先systemctl status mysql，发现服务是active的。再mysqladmin status，连接正常。那问题就在Web端。翻到wp-config.php，发现DB_HOST写的是localhost。这台机器上MySQL监听的是127.0.0.1，而PHP解析localhost时走了socket路径，socket文件权限不对。改成127.0.0.1，保存，刷新。页面回来了。

整个过程不到三分钟。但前面那四十分钟的瞎猜，才是这个报错最折磨人的地方。它不告诉你哪里错了，只告诉你"连不上"。你得靠自己一层一层剥：是凭据？是服务？是连接数？是网络？还是主机商在背后搞事？

所以下次再看到"建立数据库连接时出错"，别急着重装。先命令行连一下数据库。能连上，问题在应用配置。连不上，问题在数据库本身或者网络。这个二分法能帮你省掉至少一半的无效操作。剩下的，就是经验和耐心的事了。