数据库连接失败排查：网络、服务、认证到连接池的完整流程

第一步：确认影响范围

接到告警先别重启数据库。问两句：是所有应用都连不上，还是只有某个服务报错？大面积失联优先看网络、数据库进程和安全组变更；单应用报错重点查配置、连接池和驱动。

第二步：网络层先通后连

在应用服务器 telnet 数据库IP和端口。超时先查安全组、防火墙、VPC路由和ACL。ping能通不代表端口能通，很多人在这里栽过。用域名连接时 dig 一下解析结果，高可用环境还要确认VIP是否漂在主库。

第三步：服务端进程与连接数

登录数据库服务器，ps 或 systemctl 看进程，ss -tlnp 看端口监听。没起来就翻 error.log，磁盘满、表空间损坏、参数写错最常见。再执行 SHOW STATUS 看 Threads_connected，如果贴着 max_connections 就是连接打满了。临时调大上限或清理 Sleep 连接救急，随后调整 wait_timeout 防止堆积。

第四步：认证和权限

遇到 Access denied，先用命令行手动连，排除应用层干扰。核对密码、用户 Host 字段是否匹配客户端IP。云数据库记得去控制台检查账号权限有没有被误改。

第五步：客户端与驱动

核对 JDBC URL 里的主机、端口、库名和时区参数。MySQL 8.0 升级后，旧驱动可能不支持 caching_sha2_password，要么升级驱动，要么改认证策略。SSL 报错通常是因为证书路径错误或 useSSL 配置不当。

第六步：连接池和资源

应用报 Cannot get connection，先看连接池 maximumPoolSize 是不是太小，再查数据库里是否堆积了大量 Sleep 连接。建议给连接池开泄漏检测，配好 idleTimeout 和 maxLifetime。高峰期可以临时扩容或限流。

第七步：回溯变更与日志定因

突然断连八成是安全组规则被改了，去云控制台翻操作日志。最后把应用日志、error.log、/var/log/messages 按时间线串起来，搜 Too many connections、Connection refused、Host is blocked 这类关键词，基本能定位根因。把这套检查点写成脚本或清单，下次排查能省一半时间。