只调大--net-read-timeout常不够，因mysqldump断连还受--net-write-timeout、wait_timeout、max_allowed_packet及pt-kill等多因素影响，需同步调整并排查。
直接加 --net-read-timeout 就能解决大部分 mysqldump 中途断连问题，不需要改 MySQL 配置文件或重启服务。
为什么只调大 net_read_timeout 常常不够
mysqldump 报 Error 2013: Lost connection to MySQL server during query，表面是连接断了，但根源常不止一个超时参数在起作用：
-
net_read_timeout控制服务端等待客户端发下一条请求的时间（比如 mysqldump 发送下一个分片 SELECT） -
net_write_timeout控制服务端往 mysqldump 写数据（如 BLOB、长文本）的单次写入上限 -
wait_timeout和interactive_timeout是服务端对空闲连接的“总寿命”限制，如果导出卡顿超过这个值，连接也会被干掉
所以单独设 --net-read-timeout=120 可能压不住问题——--net-write-timeout 和服务端的 wait_timeout 得同步跟上。建议起步值统一设为 7200（2 小时），大字段多的库可设到 18000（5 小时）。
--net-read-timeout 参数必须写对，否则无效
常见拼写错误会直接让参数被忽略：
- ✅ 正确：
--net-read-timeout=120（带连字符，双短横） - ❌ 无效：
--net_read_timeout=120（下划线写法不识别） - ❌ 无效：
--netreadtimeout=120（无分隔符，mysqldump 不认）
验证是否生效：导出时加 --verbose，能看到类似 Setting net_read_timeout=120 的日志；或者在导出中途故意 kill mysqldump 进程，再检查 MySQL 的 SHOW PROCESSLIST，看连接状态是否真撑过了你设的秒数。
超时不是唯一瓶颈，别漏掉 max_allowed_packet
当导出含大字段（如 JSON、BASE64 图片、长日志）的表时，即使超时调得再大，也可能卡在 MySQL server has gone away —— 这通常是 max_allowed_packet 不够，导致单行数据超出缓冲区上限。
- 服务端和客户端都要设一致，例如都设为
512M：mysqldump --max-allowed-packet=536870912 ... - 检查当前值：
mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';" - 注意：该值不能超过服务端实际配置，否则 mysqldump 启动会报错
真正卡在 8–15 秒固定时间点失败？大概率不是超时，而是 pt-kill 在背后杀连接。用 ps aux | grep pt-kill 确认，临时停掉再试一次，比反复调参更快定位。
超时参数只是保底手段，真正稳定导出超大库，得靠按表分卷 + 先 dump 后压缩 + rsync 断点续传这套组合。参数调得再大，也扛不住管道中断或磁盘写满这种硬故障。
