mysqldump报错Error 2013或连接中断，主因是MySQL服务端net_read_timeout默认30秒过小，需在命令中加--net-read-timeout=120和--net-write-timeout=120等参数调大，无需重启MySQL。
mysqldump 报错 Error 2013 或连接中断，大概率是 net_read_timeout 不够
mysqldump 执行中途断开、卡在某个表不动、或报 Error 2013: Lost connection to MySQL server during query，十有八九不是网络真断了，而是 MySQL 服务端主动切断了连接——根源常在 net_read_timeout（服务端等待客户端发来下一条请求的超时时间）太小。默认值通常是 30 秒，而大表导出、慢网环境、或带复杂 WHERE 条件的备份很容易超时。
只改 mysqldump 命令参数就能生效，无需重启 MySQL
你不需要动 MySQL 配置文件或重启服务，直接在命令行加参数即可覆盖服务端默认值：
mysqldump --net-read-timeout=120 --net-write-timeout=120 -u user -p db_name > backup.sql-
--net-read-timeout控制服务端读取客户端请求的等待上限（比如 mysqldump 发送下一个SELECT分片时卡住） -
--net-write-timeout控制服务端往 mysqldump 进程写数据（如大量 BLOB 字段）的单次写入上限 - 两个值建议设为相同，且不低于 60；若导出含长文本/二进制字段的表，可设到 300 或更高
- 注意：参数名是
--net-read-timeout（带连字符），不是--net_read_timeout（下划线写法无效）
别漏掉客户端侧的 connect-timeout 和 timeout 参数
仅调大服务端超时还不够，mysqldump 自身也有连接建立和整体执行时限：
-
--connect-timeout=30：控制首次 TCP 连接建立的最大等待时间（适用于高延迟网络） -
--timeout=3600：某些版本支持该参数，作为整个 dump 过程的兜底总耗时限制（非所有 MySQL 版本都识别） - 如果使用
--single-transaction，还要留意事务内操作是否被innodb_lock_wait_timeout或lock_wait_timeout中断（这类属于锁等待超时，和 net_* 是两回事）
真正卡死时，先查是不是被 pt-kill 或其他监控工具干掉了
如果你确认参数已调大、但每次都在 8–15 秒左右固定时间失败，大概率不是超时问题，而是外部干预：
- 检查是否有
pt-kill进程在运行：ps aux | grep pt-kill - 它常被配置成“杀掉执行超过 10 秒的 SELECT”，而 mysqldump 的全表扫描正中靶心
- 临时停用：
sudo pkill -f "pt-kill"，再试一次 dump - 更稳妥的做法是给 pt-kill 加白名单，排除用户为
dump或命令含mysqldump的连接
net_* 超时只是表象，背后可能是锁争用、大字段溢出 max_allowed_packet、或运维脚本误杀。调参前，先用 tail -f /var/log/mysql/error.log 看服务端有没有对应 kill 记录，比盲目加 timeout 更快定位根因。
