MySQL迁移时连接超时断开，本质是
和
在作怪
长连接迁移（比如用
导出大库、或用
同步）卡在中途报
，大概率不是网络问题，而是服务端主动踢掉了空闲连接。MySQL默认
是28800秒（8小时），但很多云数据库或中间件会调得更激进——有些只设300秒（5分钟），而一个10GB的表导出可能卡在写入阶段歇上好几分钟。
实操建议：
查当前值：
和
，注意这两个值未必相等
临时调高（仅对当前会话有效）：
（别设太大，比如86400，某些版本有整型溢出风险）
真正要改配置，必须动
里的
段，加
，然后重启MySQL（热加载不生效）
如果用
，记得加
，减少锁等待带来的隐性空闲时间
mysql
dump迁移中断：不只是超时，
和
也得配平
本身也有网络层超时控制，它不看MySQL服务端的
，而是依赖自己的
和
参数。默认都是30秒，导大数据时读一行数据慢一点就直接断。
实操建议：
导出时显式加大：
这两个值必须同时设，且建议不低于服务端
的一半，否则客户端先放弃，服务端还在等
如果用管道直连（如
），还要考虑gzip压缩卡顿，此时
更要留足余量
注意：这些参数只对当前命令生效，不会写入配置文件，也不能靠
全局设置（
不读
段的timeout项）
用mysqlpump或Percona XtraBackup迁移？超时逻辑完全不同
（MySQL 5.7+）默认启用并行导出，每个线程建独立连接，每个连接都受各自
约束；而
走的是物理拷贝，不走SQL连接，所以完全不触发
，但它会受
和磁盘I/O影响导致“假死”，被误判为超时。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
实操建议：
用
时，务必加
（别盲目开太高），并确认每个线程连接的
已调高
若卡住，先看
里
是否真不动，而不是直接怀疑超时
云厂商RDS（如阿里云、腾讯云）通常禁用
物理备份权限，此时只能老实用
，且必须提前申请调高
连接池/中间件（如ProxySQL、MaxScale）会让超时更难排查
如果迁移流量经过ProxySQL这类中间件，它自己也有
和
等熔断机制。哪怕MySQL服务端没超时，ProxySQL可能因为后端响应慢，主动断掉前端连接，并返回
这种误导性错误。
实操建议：
查ProxySQL日志：
，看是否因健康检查失败下线了节点
临时绕过中间件直连MySQL IP+端口测试，快速定位是服务端还是中间件的问题
ProxySQL中
默认4秒，比MySQL的
还短，大库迁移前建议调到30秒以上
迁移时最容易被忽略的，其实是多个超时参数之间的层级关系：客户端工具（
）→ 中间件（ProxySQL）→ MySQL服务端（
）→ InnoDB内部（
）。调一个，未必管用；全调错顺序，反而更乱。
wait_timeoutinteractive_timeoutmysqldumpmysqlpumpLost connection to MySQL server during querywait_timeoutSHOW VARIABLES LIKE 'wait_timeout';SHOW VARIABLES LIKE 'interactive_timeout';SET SESSION wait_timeout = 28800;my.cnf[mysqld]wait_timeout = 28800mysqldump--single-transaction --skip-lock-tables--net-read-timeout--net-write-timeoutmysqldumpwait_timeout--net-read-timeout--net-write-timeoutmysqldump --net-read-timeout=3600 --net-write-timeout=3600 -u root -p db_name > dump.sqlwait_timeoutmysqldump | gzip > dump.sql.gz--net-write-timeout~/.my.cnfmysqldump[client]mysqlpumpwait_timeoutPercona XtraBackupwait_timeoutinnodb_log_file_sizemysqlpump--default-parallelism=2wait_timeoutXtraBackupinnobackupex --no-timestamp --stream=tar ./ | pv | cat > backup.tarpvXtraBackupmysqldumpwait_timeoutmysql-max-concurrent-client-connectionsmysql-threshold-on-connect-errorsMySQL server has gone awaySELECT * FROM stats_mysql_connection_pool WHERE status='OFFLINE_HARD';mysql-monitor_connect_timeoutconnect_timeoutmysqldumpwait_timeoutinnodb_lock_wait_timeout