导出大表时需同步调大--net-read-timeout、--net-write-timeout和wait_timeout，正确写法为--net-read-timeout=7200（双短横），并检查max_allowed_packet是否足够及pt-kill是否误杀连接。
导出大表时触发 net_read_timeout 限制
mysqldump 每次从 MySQL 服务端拉取一批数据（比如默认 1000 行），然后等待下一次请求。如果这批数据处理或传输耗时超过 net_read_timeout，服务端就会主动断开连接——错误日志里出现 Lost connection to MySQL server during query，本质是服务端“不耐烦了”。
这个参数默认只有 30 秒，而导出含 BLOB、JSON 或百万级行的大表时，单次 SELECT 可能卡在序列化、网络发送或客户端磁盘写入环节，轻松超时。
- 必须用双短横写法：
--net-read-timeout=7200（不是下划线，也不是连在一起） - 仅设这一个不够：
net_write_timeout和服务端的wait_timeout得同步调高，否则刚绕过读超时，又撞上写超时或空闲断连 - 验证是否生效：加
--verbose看日志里有没有Setting net_read_timeout=7200；或者导出中途kill -9mysqldump，再进 MySQL 执行SHOW PROCESSLIST，看连接是否真活过了你设的秒数
max_allowed_packet 不足导致半途崩溃
即使超时全调大，导出仍可能在固定位置失败，报错带 MySQL server has gone away 或直接中断——这时大概率是单行数据（比如一个 20MB 的 BASE64 字段）超过了 max_allowed_packet 限制，服务端直接切断连接。
注意：这个值要同时在服务端和 mysqldump 客户端设一致，且不能超过服务端实际允许上限，否则 mysqldump 启动就报错。
- 查当前值：
mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';" - 导出时指定：
mysqldump --max-allowed-packet=536870912（即 512MB） - 服务端配置需同步修改
[mysqld]节下的max_allowed_packet，并重启 MySQL
背后有 pt-kill 在“暗中操作”
如果你发现导出总在 8–15 秒左右精准失败，且调整所有超时参数都无效，别急着继续改配置——先检查有没有人在后台运行 pt-kill。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
这个工具常被 DBA 用来杀长事务或慢查询，但它不区分业务场景，会把正在导出的 mysqldump 连接也当成“异常连接”干掉。
- 快速确认：
ps aux | grep pt-kill - 临时停用：
kill $(pgrep pt-kill)，再重试一次导出 - 比反复调参更快定位问题，尤其在生产环境已部署监控脚本的场景下
真正卡住的往往不是 MySQL，而是管道或磁盘
超时参数只是保底手段。当导出 100GB 级别数据时，mysqldump | gzip > dump.sql.gz 这种常见写法容易因 gzip 压缩慢、磁盘写满、SSH 连接中断等外部因素失败——这些故障不会反映在 MySQL 错误日志里，但表现就是“连接丢失”。
稳定导出超大库，得放弃“一气呵成”的幻想：
- 按表分卷导出：
mysqldump db_name table1 > table1.sql - 先 dump 再压缩，避免管道阻塞
- 用
rsync --partial断点续传，而不是重跑整个命令
最容易被忽略的是：你调了 5 小时超时，但磁盘只剩 2GB 空间，导出到 99% 时照样失败，且错误信息毫无提示。
