先用telnet或nc直连3306端口验证网络连通性，若不通则排查防火墙、安全组或服务未启动；若通但应用连不上，优先检查mysql 8.0+默认require_secure_transport=on是否与客户端ssl配置不匹配，再查连接池保活与服务端wait_timeout/interactive_timeout协同配置。
Connection refused 或 Lost connection 怎么快速定位
这类报错不是 MySQL 在拒绝你，而是连接根本没发出去或中途断了。先别急着改 wait_timeout，90% 的情况是网络或客户端配置卡在半路。
常见错误现象：ERROR 2003 (HY000): Can't connect to MySQL server on 'x.x.x.x'、Lost connection to MySQL server at 'reading initial communication packet'
- 用
telnet host 3306或nc -zv host 3306直接测端口通不通，绕过所有驱动和连接池逻辑 - 如果
telnet通但应用连不上，立刻查客户端是否启用了 SSL 强制（MySQL 8.0+ 默认require_secure_transport=ON），而你的连接串没加?ssl-mode=DISABLED或对应 CA 配置 - 云环境特别注意安全组/NACL 是否放行了入方向 3306，且源 IP 是实际出口 IP（不是 NAT 网关内网地址）
HikariCP 连接池 validation-timeout 和 keepalive-time 怎么配
连接池缓存连接，但 MySQL 服务端默认 8 小时就主动断开空闲连接（wait_timeout=28800），池子却不知道——结果取出来就是“已经断掉的连接”，报 Communications link failure。
-
spring.datasource.hikari.connection-test-query=SELECT 1（MySQL 5.7+ / 8.0+ 推荐，不用isValid()） -
spring.datasource.hikari.validation-timeout=3000（毫秒，探测超时不能设太长，否则阻塞线程） -
spring.datasource.hikari.keepalive-time=30000（仅 Hikari 3.2.1+ 支持，每 30 秒发一次SELECT 1检活） -
spring.datasource.hikari.max-lifetime=1800000（30 分钟，强制回收，比wait_timeout小至少 5 分钟）
MySQL 服务端 wait_timeout 和 interactive_timeout 必须一起改
看到 Communications link failure 就该查 wait_timeout：这个错误不是网络断了，而是 MySQL 主动“踢人”了——连接空闲太久，服务端直接断开 TCP 连接。
-
wait_timeout控制非交互式连接（比如 Java 应用 JDBC 连接）空闲多久断开 -
interactive_timeout只影响mysql命令行这种交互式连接，对应用几乎无影响，但 JDBC 初始化时会按客户端类型选其一赋值，所以必须同步修改 - 永久生效：改
/etc/my.cnf或/etc/mysql/conf.d/*.cnf，加这两行：[mysqld]<br>wait_timeout = 2592000<br>interactive_timeout = 2592000
然后systemctl restart mysqld（Docker 容器需挂载配置或进容器改） - 别信
autoReconnect=true——MySQL 5.5+ 已废弃，不解决根本问题，还可能掩盖连接泄漏
Too many connections 错误怎么判断是不是 sleep 连接堆积
大量 SLEEP 状态连接长期不释放，本质是 wait_timeout 设得过大 + 连接池没健康检查，导致连接池持续返回已失效连接，最终耗尽 max_connections。
- 执行
SHOW PROCESSLIST，重点看Command列为Sleep且Time值远大于你设的wait_timeout - 查当前使用率：
SHOW GLOBAL STATUS LIKE 'Threads_connected'和SHOW VARIABLES LIKE 'max_connections'，计算比例是否接近 100% - 临时缓解：
SET GLOBAL wait_timeout = 300（5 分钟），但必须配合连接池的keepalive-time和max-lifetime才能治本 - 别只调大
max_connections：内存吃紧会导致性能雪崩，优先清理无效连接而不是扩容
require_secure_transport=ON，而绝大多数 Spring Boot 项目连接串没显式声明 SSL 策略，导致连接在 TLS 握手阶段静默失败——它不报 SSL 错误，只表现为超时或 Lost connection。
