connection reset 的真实原因是 mysql 服务端主动中断连接，核心诱因是 max_allowed_packet 过小或 net_read_timeout 不足，需同步调整服务端参数（max_allowed_packet=512m、net_read_timeout=3600、wait_timeout=28800）、客户端参数（--skip-extended-insert、分块导出、禁用--compress）及系统 tcp 缓冲区与 keepalive 设置。
备份时触发 Connection reset 的真实原因
这不是网络“不稳定”导致的，而是 mysqldump 或客户端在读取大结果集时，被 MySQL 服务端主动中断连接。核心诱因是 max_allowed_packet 过小或 net_read_timeout 不足以支撑单次 dump 流式传输耗时，尤其当表含大字段（TEXT、BLOB）或使用 --single-transaction 时事务持续时间拉长。
必须调的三个 MySQL 服务端参数
仅改客户端超时没用，服务端才是断连源头。需在 my.cnf 中调整以下三项并重启 MySQL：
-
max_allowed_packet = 512M：默认 4MB，备份含大字段时极易触顶；设为 512M 可覆盖绝大多数场景 -
net_read_timeout = 3600：默认 30 秒，dump 过程中服务端等待客户端“接收下一批数据”的上限，设为 1 小时更稳妥 -
wait_timeout = 28800：虽不直接作用于 dump 连接（它属交互式），但若用mysql命令行管道导入导出，仍可能受其影响，统一设为 8 小时避免干扰
mysqldump 客户端关键参数组合
光调服务端不够，客户端命令本身也得规避流式阻塞：
- 加
--skip-extended-insert：避免单条 INSERT 超过max_allowed_packet，但会增大 SQL 文件体积 - 强制分块导出：
--where="id BETWEEN 1 AND 100000"配合循环，比全量 dump 更可控 - 禁用压缩传输（如果走远程）：
--compress在高延迟链路上反而增加超时风险，建议关闭 - 显式指定超时：
mysql --connect-timeout=60 --read-timeout=3600 -e "SELECT ..."替代部分 dump 场景
缓冲区与网络层绕不开的细节
TCP 层缓冲区不足也会放大重置概率，尤其在千兆以上带宽、高延迟（如跨云厂商）环境下：
- Linux 系统级：检查
/proc/sys/net/ipv4/tcp_rmem，三元组建议设为4096 262144 16777216（min/default/max），避免接收窗口太小 - MySQL 客户端驱动：pymysql 或 mysqlclient 若用于脚本化备份，需手动设置
read_timeout=3600参数，否则继承系统默认 30 秒 - 不要依赖 NAT 网关保活：阿里云 SLB、AWS ALB 默认空闲 300 秒断连，必须在服务端开启 TCP keepalive 并设
tcp_keepalive_time=600
真正卡住人的从来不是“要不要加大超时”，而是哪一层（MySQL 内核 / TCP 栈 / 中间设备）先动手关连接——得一层层对齐，漏一层就白调。
