导出大表时需同步调大--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 -9 mysqldump，再进 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。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 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% 时照样失败，且错误信息毫无提示。