ERROR 2006根本原因是连接被主动切断，核心在于客户端和服务端的max_allowed_packet配置过小或语句执行超wait_timeout；需同步调整两端参数，并在mysqldump命令中显式指定--max_allowed_packet及超时选项，同时注意UTF8MB4、--skip-extended-insert及环境层限制。
mysqldump报ERROR 2006不是服务崩了，是连接被主动切断
根本原因就两个：客户端或服务端的 max_allowed_packet 太小，或者某条语句执行时间超过了 wait_timeout。它和SQL文件损坏、MySQL宕机完全无关——只是连接中途断了，而mysqldump没重连机制，直接报错退出。
必须同时调客户端和服务端的max_allowed_packet
只改 my.cnf 里的 [mysqld] 段没用。mysqldump 客户端启动时会从服务端读一次该值并缓存，不会动态刷新。你得在命令里显式指定：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
mysqldump --max_allowed_packet=512M -u user -p db_name > backup.sql
-
--max_allowed_packet必须大于你要导出的最大单行数据（比如含大BLOB或长TEXT字段的行） - 服务端也要同步设：在
[mysqld]和[mysqldump]段都写max_allowed_packet = 512M，改完重启mysqld - 如果导出含 emoji 或四字节 UTF-8，加
--default-character-set=utf8mb4，否则解析可能卡死，伪装成 2006
wait_timeout不够也会触发2006，尤其导大表时
哪怕 max_allowed_packet 足够，一条超长 INSERT INTO ... VALUES (),(),()...（几万行拼一起）执行时间超过 wait_timeout，照样断连。
- 服务端调高：在
my.cnf的[mysqld]段加wait_timeout = 600、interactive_timeout = 600 - mysqldump 命令里加超时参数：
--connect-timeout=600 --net-read-timeout=600 --net-write-timeout=600 - 更稳妥的做法是避免拼超长 INSERT：加
--skip-extended-insert，让每行只插一条，既降低单语句执行时长，也方便后续拆分
别漏掉环境层的隐性限制
即使参数全对，也可能被其他层拦住：
- PHP 环境（如 phpMyAdmin）：还要检查
mysqli.reconnect是否为 1，否则连接断后不重试；max_execution_time和memory_limit过低也会导致中途退出，看起来像 2006 - 文件系统：输出路径磁盘满、inode 耗尽、SELinux 限制写入，都会让
mysqldump > file.sql静默失败或报错 - 临时目录空间：mysqldump 内部用
/tmp做缓冲，df -h /tmp看是否满；可加--tempdir=/path/to/large/disk指定
max_allowed_packet 在客户端、服务端、甚至中间件（如 PHP 的 mysqli 扩展）上是三套独立配置，缺一不可；且 mysqldump 不会自动继承服务端值，必须显式传参或改其专属段。** 
