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