mysqldump 的 --net-read-timeout 必须与 --net-write-timeout 配平且不超服务端 wait_timeout，否则单独设置无效；因写入阻塞（如gzip压缩或磁盘慢）会先触发默认30秒的写超时导致断连。
mysqldump 的 --net-read-timeout 不是“调大就稳”，它必须和 --net-write-timeout 配平，且不能脱离服务端 wait_timeout 单独生效
为什么只加 --net-read-timeout 会失效
mysqldump 自身实现了一套网络层超时控制，完全不读取 MySQL 服务端的 wait_timeout。但它有两个独立开关：--net-read-timeout（收包超时）和 --net-write-timeout（发包超时）。如果只设前者，后者仍用默认 30 秒——一旦导出过程中 gzip 压缩卡住、或目标磁盘写入慢，--net-write-timeout 就先触发断连，前面的读超时设置等于白配。
- 错误现象：日志里出现
Lost connection to MySQL server during query，但SHOW PROCESSLIST显示源库连接还处在Sleep状态，说明是客户端主动放弃 - 根本原因：mysqldump 进程在等待往管道/文件写入时超时，不是 MySQL 服务端踢人
- 必须同时设置两个参数，且值一致：例如
--net-read-timeout=3600 --net-write-timeout=3600
参数值不能随便设成 86400
虽然设成 24 小时看起来“保险”，但实际有风险：
- MySQL 5.7 及部分云厂商定制版对超时值做 int32 有符号整型校验，86400 虽安全，但若误写成 100000，可能被截断为负数，导致 mysqldump 内部逻辑崩溃
- 更稳妥的做法是设为服务端
wait_timeout的一半（比如服务端是 28800 秒，则设 14400），既留余量，又避免溢出 - 注意：这些参数只对当前命令有效，
~/.my.cnf中的[client]段不会被 mysqldump 读取
管道场景下 --net-write-timeout 要额外加码
当使用 mysqldump | gzip > dump.sql.gz 这类管道时，写入延迟不再只取决于磁盘 I/O，还叠加了压缩耗时。gzip 在处理大 BLOB 字段时可能卡住数秒，此时 --net-write-timeout 必须覆盖这个毛刺周期。
- 实操建议：若导出含大量 TEXT/BLOB 的库，把
--net-write-timeout设为--net-read-timeout的 1.5 倍（如 3600 → 5400） - 验证方式：导出中途手动 kill -STOP gzip 进程几秒，观察是否断连；若断，说明 write timeout 仍不足
- 替代方案：改用
mysqldump ... > dump.sql && gzip dump.sql分两步，彻底规避管道写阻塞
真正决定“能不能扛住抖动”的其实是服务端配置
客户端 timeout 再大，也救不了服务端提前断连。必须确认两端协同：
- 查服务端：
SHOW VARIABLES LIKE 'wait_timeout';，确保不低于你设的--net-read-timeout - 若服务端是云数据库（如阿里云 RDS、腾讯云 CDB），其
wait_timeout往往被强制设为 300～600 秒，此时 mysqldump 的 timeout 再大也没用——必须联系厂商调高，或换用mydumper - 别漏掉
interactive_timeout：mysqldump 建立的是非交互连接，只受wait_timeout约束，但某些中间件（如 ProxySQL）会统一按interactive_timeout判定，需一并检查
网络抖动本身不可控，但超时参数的错配会让问题从“偶发中断”变成“必现失败”。最关键的不是堆数值，而是让客户端读写超时、服务端空闲超时、以及实际 I/O 延迟三者形成梯度覆盖——少一个环节，抖动就会暴露出来。
