mysql如何解决mysqldump超时问题_调整net_read_timeout参数

解决mysqldump报错Error 2013或连接中断

mysqldump报错Error 2013的主因：net_read_timeout过小

当执行mysqldump时遇到连接中途断开、进程卡住，或直接提示Error 2013: Lost connection to MySQL server during query错误，通常并非物理网络故障。其核心原因往往是MySQL服务端参数net_read_timeout设置值过小，导致服务端主动断开了连接。该参数默认值通常为30秒，在导出大表、网络延迟或复杂查询处理缓慢时，极易触发此超时限制。

通过mysqldump命令参数调整，无需重启MySQL

解决此问题无需修改MySQL全局配置或重启服务，可直接在mysqldump命令中添加参数覆盖默认值：

• 典型命令示例：mysqldump --net-read-timeout=120 --net-write-timeout=120 -u user -p db_name > backup.sql
• --net-read-timeout用于设置服务端读取客户端请求的最大等待时间。
• --net-write-timeout用于控制服务端向客户端发送单次数据包的时间上限。
• 建议将两值设为相同，且不低于60秒。若表包含大文本或BLOB字段，可适当提高至300秒或更高。
• 注意参数需使用连字符--net-read-timeout，下划线形式--net_read_timeout无效。

同时调整客户端超时参数

除服务端参数外，也需关注mysqldump客户端的超时设置：

• --connect-timeout=30：控制建立TCP连接的最大等待时间，适用于高延迟网络环境。
• --timeout=3600：为整个dump过程设置总时间上限（注意部分MySQL版本可能不支持此参数）。
• 若使用--single-transaction选项，需注意事务可能受innodb_lock_wait_timeout等锁超时参数影响，这与网络读写超时属不同范畴。

排查外部工具干预：如pt-kill

若调整超时参数后问题依旧，且失败时间点固定（如总是在数秒内中断），则可能存在外部工具强制终止查询：

• 检查是否有pt-kill等监控工具在运行：ps aux | grep pt-kill。
• 此类工具常配置为自动终止长时间运行的查询（如超过10秒的SELECT），mysqldump的全表扫描易被误杀。
• 可临时停止工具验证：sudo pkill -f "pt-kill"，再重新执行dump。
• 长期解决方案是为pt-kill配置白名单，排除备份用户或包含mysqldump关键词的连接。

网络超时报错可能是多种问题的表象，包括锁争用、数据包超过max_allowed_packet限制或运维脚本误杀等。建议优先查看MySQL错误日志：tail -f /var/log/mysql/error.log，以快速定位根本原因。