改wait_timeout和interactive_timeout能解决问题，因MySQL用二者分别控制非交互式和交互式空闲连接的硬性超时时间，服务端据此主动断连。
MySQL连接超时断开，本质是服务端主动踢掉空闲连接，不是客户端或网络问题——直接改 wait_timeout 和 interactive_timeout 才治本。
为什么改这两个变量就能解决问题
MySQL用两个独立变量控制空闲连接生命周期：wait_timeout 管非交互式连接（比如 JDBC、Python 的 PyMySQL/SQLAlchemy），interactive_timeout 管交互式连接（比如命令行 mysql -u root -p）。默认都是 28800 秒（8 小时），只要连接在这段时间内没发任何 SQL，服务端就直接 close TCP 连接。客户端再发请求时，拿到的就是“Last packet sent X ms ago”这类错误。
它们不是“建议值”，而是硬性截止时间；也不受客户端重连参数影响（比如 autoReconnect=true 在 MySQL 5.6+ 已被弃用且无效）。
怎么改才真正生效
必须同时改两个变量，且优先写进配置文件永久生效，仅执行 SET GLOBAL 是临时的（重启 MySQL 后还原）。
- 编辑
/etc/my.cnf（Linux）或my.ini（Windows），在[mysqld]段落下添加：
[mysqld] wait_timeout = 31536000 interactive_timeout = 31536000
数值单位是秒，这里设为 365 天，相当于禁用空闲断连（生产环境可按需设为 24~72 小时）。
- 保存后必须重启 MySQL 服务：
sudo systemctl restart mysql或sudo service mysqld restart - 验证是否生效：
mysql -u root -p -e "SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout';"
注意：不能只改其中一个。JDBC 连接初始化时会根据连接类型自动继承对应变量值，若只调高 wait_timeout 而 interactive_timeout 仍为默认，某些驱动行为可能异常。
常见踩坑点
很多团队试过但失败，问题出在这些细节上：
-
SET GLOBAL wait_timeout = 31536000命令看似成功，但新连接仍用旧值——因为该语句只影响后续新建会话的初始值，已有连接不受影响，且重启即失效 - 改完配置不重启服务，或重启了但没确认配置文件路径是否正确（比如 MySQL 实际读的是
/etc/mysql/my.cnf而非/etc/my.cnf） - 应用用了连接池（如 HikariCP、Druid），却没配
connection-test-query或validation-timeout，导致池里缓存了已断开的连接，报错仍会发生 - 云数据库（如阿里云 RDS、腾讯云 CDB）不允许修改全局变量，只能通过控制台调整参数模板，且部分参数需重启实例才生效
最稳妥的做法：配置文件改 + 服务重启 + 应用层加连接有效性检查（例如 HikariCP 的 connection-test-query=SELECT 1）。
要不要调大 net_read_timeout / net_write_timeout
这两个变量管的是「单次 SQL 执行过程中的读写等待」，和空闲断连无关。只有当某条查询本身执行太久（比如大表 JOIN、没索引的 WHERE），才会触发它们。如果错误日志里明确出现 Lost connection to MySQL server during query，才需要看它；如果是 ... was X ms ago，就不用动。
真正容易被忽略的是：即使 wait_timeout 设得再大，如果中间经过 NAT 网关、SLB 或防火墙，它们往往自带 5~30 分钟的空闲连接清理策略——这时光调 MySQL 没用，得同步调整中间设备的 keepalive 设置。
