mysqldump中途断连主因是MySQL服务端主动断开连接，典型表现为“Lost connection during query”或dump文件缺失结束标记；根本解决需加--single-transaction（InnoDB专用），配合--connect-timeout和--max-allowed-packet调优，而非依赖autoReconnect。
mysqldump中途断连，不是网络问题而是MySQL主动关连接
备份中断往往不是SSH断了或本地终端关了，而是MySQL服务端自己把连接杀了。关键信号是日志里出现 Lost connection to MySQL server during query 或 dump 文件末尾缺 UNLOCK TABLES、/* End of dump */。这说明 mysqldump 进程还在跑，但 MySQL 已经单方面断开了 socket。
必须加 --single-transaction，否则InnoDB表一卡就锁死
没加 --single-transaction 的备份，在事务未提交前会触发隐式锁表；一旦遇到大表扫描或慢查询，整个库的写操作会被堵住，你自己也连不进去查 SHOW PROCESSLIST。更糟的是，这种锁状态在 nohup 或 tmux 里完全不可见。
- 只对 InnoDB 表生效，MyISAM 仍需
--lock-tables（但生产环境应避免 MyISAM） - 不能和
--lock-tables同时用，否则会冲突报错 - 配合
--routines和--triggers时，确保用户有SELECT ROUTINE权限，否则备份中途静默失败
别信 autoReconnect=true，它对 mysqldump 没用
autoReconnect=true 是 JDBC 驱动参数，只影响应用层连接池，对 mysqldump 这种一次性 CLI 工具完全无效。mysqldump 连接断开后不会重试，只会退出并留下半截文件。
- 验证方式：手动 kill 掉 mysqldump 对应的线程，观察是否自动重连——结果永远是进程退出
- 真正起作用的是
--connect-timeout=30和--max-allowed-packet=512M，防止因包过大或握手超时被拒 - 如果备份涉及 BLOB 字段，
max_allowed_packet必须大于最大单条记录，否则会在某张表中途报错退出
后台运行只是表象，IO 和锁才是真瓶颈
nohup 或 tmux 能让进程不死，但解决不了磁盘写满、CPU 打满、或者 SELECT 死卡在 Sending data 状态。这些情况会让 mysqldump “看起来在跑”，实则卡在内核态等 I/O 或等待锁释放。
- 执行前先跑
iostat -x 1，确认 %util --compress 反而加重 CPU 压力 - 备份中执行
SHOW PROCESSLIST，看到 State 长时间停在Sending data或Copying to tmp table，说明 SQL 层已卡住，后台再稳也没用 - 用
mysqldump --no-create-info --skip-triggers --skip-routines database_name table_name > test.sql快速验证单表是否可导出，排除触发器/存储过程引发的隐式锁
真正难处理的从来不是怎么让备份“跑起来”，而是怎么让它“跑得明白”：IO 是否饱和、锁是否堆积、SQL 是否真在执行——这些状态在后台进程里全被黑盒化了。
