数据库连接失败排查：四层顺序定位的高效方法

线上应用突然刷出一堆数据库连接报错，排查时先别急着重启服务。连接失败的原因高度集中在几个固定维度，按网络、认证、服务状态、连接池的顺序排查，是定位问题最高效的方法。

第一层：排查网络通路

先在客户端机器上测试数据库端口连通性。比如执行 telnet 数据库IP 3306，如果直接超时或拒绝，大概率是中间防火墙、云安全组或网络策略拦截。此时需检查安全组规则、主机 iptables，以及代理策略是否变动。如果 telnet 能通但马上断开，说明网络层没问题，继续往上层排查。

第二层：核对认证与权限

网络通了却报认证失败，先核对用户名、密码和来源IP授权。常见情况是DBA近期调整了权限表，或密码过期策略触发导致账户被锁。此外，部分数据库对来源IP有白名单限制，应用扩容后新机器IP未加授权也会直接拒绝连接。

第三层：确认服务端进程与资源

如果连认证错误都没出现，需登录数据库服务器检查进程状态。执行 ps 命令查看守护进程是否存活。若进程消失，立刻查看错误日志，重点排查磁盘写满、OOM被系统杀掉，或配置文件修改错误导致启动失败。其中磁盘空间不足是最常见原因，用 df 命令即可快速确认。

第四层：排查连接数耗尽与配置陷阱

若报错为 Too many connections，可通过本地 socket 登录数据库，查看当前连接数和 max_connections 上限。临时救急可在线调大连接数，但根本原因多为连接泄漏或短连接风暴。同时注意两个配置陷阱：一是 bind-address 绑定了 127.0.0.1 导致远程连不上；二是 DNS 解析卡顿导致连接超时，建议直接用IP连接绕过。此外，wait_timeout 设置过短会导致连接池中的空闲连接被静默断开，应用复用时即报错。

日常预防与监控建议

高效排错不仅靠事后补救，更需日常预防。建议将连接数告警阈值设在 max_connections 的 70% 左右以便提前预警。应用侧务必使用连接池，并开启空闲检测与连接回收。定期排查慢查询，避免长事务占用连接不释放。集群架构下，客户端配置多节点故障切换，可显著降低单点连接失败的影响面。