MySQL远程连接超时主因是服务端wait_timeout与客户端socketTimeout不匹配、DNS解析卡顿及连接池复用“僵尸连接”;需同步调低wait_timeout/interactive_timeout(如300秒)、显式配置socketTimeout(如600000毫秒)、启用skip-name-resolve并配置连接池有效性检测(如HikariCP设connection-test-query=SELECT 1)。
MySQL远程连接超时,八成不是网络卡,而是服务端 wait_timeout 和客户端 socket 超时参数没对齐,再加个 DNS 解析卡顿或连接池复用“僵尸连接”,问题就稳稳坐实了。
这两个值默认是 28800 秒(8 小时),但云数据库、Docker 镜像常悄悄改成 300~600 秒。客户端连接池若还按“长期有效”去复用连接,拿到的大概率是 MySQL 已静默关闭的假连接。
SELECT @@wait_timeout, @@interactive_timeout;
SET GLOBAL wait_timeout = 300; 和 SET GLOBAL interactive_timeout = 300;
/etc/my.cnf 的 [mysqld] 段下加两行:[mysqld]wait_timeout = 300interactive_timeout = 300
JDBC 的 socketTimeout(单位毫秒)控制单次 I/O 等待上限,和 MySQL 的 wait_timeout 完全不是一回事。它不关心连接空闲多久,只管“发出去之后等多久没回包就炸”。SQL 执行本身耗时长(比如大表 COUNT),socketTimeout 却设成默认 0 或 30000,就会在结果返回途中被客户端强行中断。
jdbc:mysql://host:3306/db?socketTimeout=600000&connectTimeout=5000(即 10 分钟响应等待)read_timeout 参数,SQLAlchemy 还得开 pool_pre_ping=True
MySQL 默认会对每个新连上的客户端 IP 做反向 DNS 解析。如果 DNS 不通、慢或 /etc/hosts 缺条目,连接会卡住几秒甚至几十秒——你看到的“连接慢”,其实是它在傻等 DNS 回复。
SELECT USER(), CURRENT_USER();,如果 CURRENT_USER() 返回的是 IP(如 [email protected])但连接明显延迟,基本就是它[mysqld] 段加 skip-name-resolve,然后重启 MySQLGRANT 语句里的 host 必须写 IP 或 %,不能再用主机名(如 'user'@'web01' 会失效)哪怕服务端和客户端超时都调对了,连接池仍可能把已断开的连接塞给业务线程。MySQL 断连是静默的,客户端不发包根本不知道自己连的是个空壳。
connection-test-query=SELECT 1、idle-timeout=30000、max-lifetime=1800000(必须小于 MySQL 的 wait_timeout)testOnBorrow=true 不够,得配 validationQuery=SELECT 1 + testWhileIdle=true + timeBetweenEvictionRunsMillis=30000
真正难搞的从来不是单点参数,而是服务端 wait_timeout、客户端 socketTimeout、连接池 max-lifetime 三者数值关系没理清,再叠加上云厂商 SLB 的 5 分钟空闲清理策略——这时候调哪个都像隔靴搔痒。
Tplink企业版路由器WiFi名称的默认设置介绍(Tplink企业版路由器WiFi名称的默认设置是什么)
Tplink路由器灯常亮无法上网的原因分析(如何解决Tplink路由器灯常亮无法上网的问题)
Tplink千兆企业级路由器自动重启的作用和优势介绍(如何设置Tplink千兆企业级路由器自动重启功能)
一根天线的tplink路由器有哪些(一根天线的Tplink路由器的特点和优势介绍)
tplink路由器外网访问不了nas(Tplink路由器外网访问NAS的原因分析)
Tplink无法搜到路由器的原因分析(如何解决Tplink无法搜到路由器的问题)