解决mysqldump报error 2013需同步调大--net-read-timeout、--net-write-timeout和wait_timeout三参数，单调其一无效；还需排查pt-kill误杀、max_allowed_packet不足及tb级场景应改用xtrabackup。
mysqldump报Error 2013：超时参数必须成对调大
只加--net-read-timeout=120基本没用，--net-write-timeout和wait_timeout必须同步跟上。mysqldump读数据慢会触发前者，写大字段（如JSON、BASE64图片）卡住则触发后者；而服务端空闲连接被杀，是wait_timeout在起作用。
实操建议：
- 导出命令显式指定三者：
mysqldump --net-read-timeout=7200 --net-write-timeout=7200 --connect-timeout=600 -u user -p db_name > dump.sql - 服务端临时生效（无需重启）：
SET GLOBAL wait_timeout = 7200; SET GLOBAL interactive_timeout = 7200; - 验证是否生效：导出中途执行
SHOW PROCESSLIST，看连接的Time列是否真能超过你设的秒数
导出卡在8–15秒固定时间？先查pt-kill
不是超时配置低，而是外部工具在“精准击杀”。很多运维环境默认部署pt-kill，规则常设为“杀掉运行超10秒的SELECT”，而mysqldump全表扫描正好命中。
快速确认和绕过：
- 执行
ps aux | grep pt-kill，看是否有活跃进程 - 临时停掉：
sudo pkill -f "pt-kill"，再试一次导出 - 更稳妥：给
pt-kill加白名单，排除用户为dump或命令含mysqldump的连接
大字段+超大表导致“MySQL server has gone away”
这不是连接断了，是单行数据超出缓冲区——max_allowed_packet成了真正瓶颈。即使超时全调到5小时，只要一行含10MB Base64图片，照样报错。
必须两端一致设置：
- 查当前值：
mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';" - 导出时加：
--max-allowed-packet=536870912（即512M），注意必须≤服务端实际值 - 若服务端值太小，需改
my.cnf中[mysqld]段的max_allowed_packet = 512M并重启 - 导入时客户端也要同步加该参数，否则
mysql命令自身会截断
TB级迁移别硬扛mysqldump，换XtraBackup
mysqldump本质是单线程SQL逻辑导出，TB级数据导出本身就要十几小时，还极易受锁、日志、字符集转换拖累。物理层工具才是正解。
Percona XtraBackup能压进4小时的关键点：
- 不走SQL解析，直接拷贝InnoDB页，跳过锁表和字符集转换开销
- 支持
--parallel=8 --compress --stream=xbstream，万兆网+NVMe盘实测8.2TB总耗时3h42m - 必须满足前提：GTID开启、源目标版本兼容、
innodb_file_per_table=ON、lower_case_table_names一致 - prepare操作必须在目标机执行，不能在源机做——否则apply log阶段会失败
真正卡住的往往不是参数数字，而是误把逻辑导出当物理迁移用，或在pt-kill开着的情况下反复调net_read_timeout。TB级迁移，第一步不是改参数，是确认路径选对没。
