MySQL连接超时中断事务本质是wait_timeout或interactive_timeout触发，事务不延长连接生命周期；需结合应用层心跳、短事务设计及云平台参数管理。
MySQL 连接超时中断事务，本质是 wait_timeout 或 interactive_timeout 在作祟
事务执行到一半突然报错 Lost connection to MySQL server during query 或 MySQL server has gone away，大概率不是网络问题，而是连接被服务端主动断开了。MySQL 默认对空闲连接施加时间限制：非交互式连接（如应用用 JDBC/PHP PDO 建的）受 wait_timeout 控制（默认 28800 秒，即 8 小时），但很多云数据库或容器化部署会调低到 300–600 秒；交互式连接（如 mysql 命令行）则看 interactive_timeout。事务本身不延长连接生命周期——只要连接空闲超过阈值，哪怕事务还没提交，连接就被干掉。
- 查当前值：
SHOW VARIABLES LIKE 'wait_timeout';和SHOW VARIABLES LIKE 'interactive_timeout'; - 临时修改（重启失效）：
SET GLOBAL wait_timeout = 28800;（需 SUPER 权限） - 永久生效必须改配置文件（如
/etc/mysql/my.cnf或/etc/my.cnf），在[mysqld]段落下：wait_timeout = 28800<br>interactive_timeout = 28800
- 注意：
wait_timeout对已建立连接只影响后续空闲期，不会延长当前连接剩余寿命
应用层不能只靠调大 wait_timeout，得配合连接池心跳和事务边界控制
光调服务端参数治标不治本。比如 Java 应用用 HikariCP，如果连接池里存着一个空闲了 600 秒的连接，而 MySQL 已设 wait_timeout=600，那下一次从池里取出它执行事务前，连接大概率已失效。这时候需要双向配合：
- HikariCP 建议配
connection-test-query=SELECT 1（MySQL 8.0.19+ 改用connection-test-query=SELECT 1或更推荐connection-init-sql=SELECT 1） - 开启
test-on-borrow=true（或现代版用validation-timeout+connection-test-query） - 关键：避免长事务——把一个耗时 10 分钟的“事务”拆成多个小事务，每段处理完立刻
COMMIT，别让单个事务横跨多次网络往返 - Python 的
pymysql或mysql-connector-python需手动在connect()里加autocommit=False并显式控制commit()/rollback()，否则默认 autocommit 可能掩盖连接复用问题
max_allowed_packet 和 net_read_timeout 也会伪装成“连接超时”
有些报错看着像连接断开，实际是数据包太大或读响应太慢被掐断。比如事务里执行一个超大 INSERT ... SELECT 或 LOAD DATA，卡在传输阶段，触发的是 net_read_timeout（默认 30 秒），不是 wait_timeout。这时候调 wait_timeout 完全没用。
- 查当前值：
SHOW VARIABLES LIKE 'max_allowed_packet';、SHOW VARIABLES LIKE 'net_read_timeout'; - 若涉及批量写入，先确认
max_allowed_packet是否够用（比如设为64M：SET GLOBAL max_allowed_packet = 67108864;） -
net_read_timeout控制服务器等待客户端发送请求的时间，大事务中客户端发完 SQL 后等结果太久会触发它；net_write_timeout则管服务器发回数据给客户端的阶段 - 这些 timeout 类参数修改后，对已有连接不生效，只影响新连接
云数据库（RDS/Aurora/Cloud SQL）上改配置要格外小心
阿里云 RDS、AWS RDS、腾讯云 CDB 这些托管服务，通常不开放 SET GLOBAL 权限，也不能直接改 my.cnf。所有参数必须走控制台或 API 修改，并且部分参数（如 wait_timeout）可能被平台强制锁定或仅允许在特定参数组中调整。
- 先去控制台找「参数组」或「数据库参数」页面，搜索
wait_timeout - 注意区分「动态参数」和「静态参数」：前者修改后立即对新连接生效；后者需重启实例（意味着停机）
- 有些云厂商会额外加一层连接代理（如 ProxySQL、AliSQL 的连接池），实际生效的可能是代理的 idle timeout，而非 MySQL 本身的
wait_timeout - 最稳妥的做法：在应用侧做好连接有效性检测 + 短事务 + 重试逻辑，别把命全交给服务端 timeout 配置
wait_timeout 还是出问题，就是卡在这儿。 
