根本原因是MySQL服务端wait_timeout与客户端socketTimeout不匹配且未启用连接有效性检测；需同步调整服务端wait_timeout/interactive_timeout、JDBC socketTimeout及连接池validationQuery等参数，并排查DNS解析、认证插件和云厂商SLB超时等干扰因素。
MySQL 8.0 远程执行 SQL 出现超时中断，根本原因通常不在网络层，而是服务端 wait_timeout 和客户端 socketTimeout 不匹配，且未启用连接有效性检测。
为什么远程执行 SQL 会突然报 “The last packet successfully received…”
这个错误不是 MySQL 主动断开，而是客户端（如 Java 的 JDBC、Python 的 pymysql）在读取响应时卡住超过设定阈值后主动抛出的异常。关键点在于：
- MySQL 服务端的
wait_timeout（默认 28800 秒）只控制“空闲连接”何时被回收，不干预正在执行的查询 - 真正起作用的是 JDBC URL 中的
socketTimeout（单位毫秒），它限制单次网络 I/O 的等待上限 - 如果 SQL 执行本身耗时长（比如大表 COUNT、复杂 JOIN），但
socketTimeout设得太小（如默认 0 或 30000），就会在结果返回途中被客户端强制中断 - 远程场景下，中间防火墙、云厂商 SLB 常有 5~10 分钟的空闲连接清理策略，比 MySQL 的
wait_timeout更激进
必须同步调整的三个超时参数
单一修改某一处无法根治问题，需服务端 + 客户端协同：
- MySQL 服务端：降低
wait_timeout和interactive_timeout到 120~300 秒，避免连接池复用“僵尸连接”SET GLOBAL wait_timeout = 120;SET GLOBAL interactive_timeout = 120; - MySQL 配置文件（
/etc/mysql/my.cnf或/etc/my.cnf）中持久化：
[mysqld] wait_timeout = 120 interactive_timeout = 120
- JDBC 连接串必须显式指定
socketTimeout，且值要大于预期最长 SQL 执行时间（例如设为 600000 即 10 分钟）：jdbc:mysql://host:3306/db?socketTimeout=600000&connectTimeout=5000
连接池侧必须开启有效性验证
即使超时参数调对了，连接池仍可能把已失效的连接分配给业务线程。以 Druid 为例，仅靠 testOnBorrow=true 不够，因为 MySQL 的 wait_timeout 断连是静默的，客户端无感知：
- 必须启用
validationQuery=SELECT 1并配合testWhileIdle=true+timeBetweenEvictionRunsMillis=30000 - HikariCP 则需设置：
connection-test-query=SELECT 1idle-timeout=30000max-lifetime=1800000（小于 MySQL 的wait_timeout） - Python 的
SQLAlchemy需配置pool_pre_ping=True，否则首次 fetch 时才暴露连接失效
容易被忽略的 DNS 和认证插件陷阱
远程连接慢或偶发超时，未必是超时参数问题：
- MySQL 启动时若未配置
skip-name-resolve，每次连接都会尝试反向 DNS 解析客户端 IP，远程环境极易卡顿[mysqld]skip-name-resolve - MySQL 8.0 默认使用
caching_sha2_password插件，旧版 JDBC 驱动（如 5.1.x）不兼容，会导致连接 hang 住或超时
改用mysql_native_password：ALTER USER 'user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 云数据库（如阿里云 RDS、腾讯云 CDB）后台可能强制启用 SSL，而客户端未配
useSSL=true&requireSSL=true也会导致连接阶段超时
最麻烦的不是参数设多少，而是不同层级的超时（TCP connect、JDBC socket、MySQL wait、连接池 idle、防火墙 keepalive）彼此嵌套又不透明。线上排查时，优先抓包确认是哪一层先断的，再针对性调参。
