根本原因是客户端和服务器端 max_allowed_packet 未同步生效：需同时设置服务端配置文件的 max_allowed_packet 和 mysqldump 命令的 --max-allowed-packet 参数，且该参数须置于命令最前、单位大写（如512m），否则无效。
mysqldump 备份时报错 Packet too large
根本原因是 MySQL 客户端（mysqldump）和服务器端对单个网络包大小有默认限制，而含 MEDIUMTEXT、LONGTEXT、MEDIUMBLOB、LONGBLOB 的表在导出时容易突破这个限制，直接报错中断。
关键不是“调大就行”，而是要让客户端和服务器两端的 max_allowed_packet 同步生效：
- 服务端配置（
my.cnf或my.ini）里改max_allowed_packet = 512M，仅影响服务器接收能力，不影响mysqldump自身发送行为 -
mysqldump默认用的是客户端协议，它自己也有独立的--max-allowed-packet参数，必须显式指定，且值不能超过服务端设置上限 - 如果只改服务端没改
mysqldump参数，备份仍会失败；反过来只改mysqldump参数但服务端太小，也会被拒绝
mysqldump 命令中怎么正确传参 --max-allowed-packet
这个参数必须放在命令最前面（或紧挨着 mysqldump），不能丢在最后，否则会被忽略。它的单位支持 K、M、G，但注意：不写单位默认是字节，容易误设成 64（即 64 字节）导致更早失败。
推荐写法：
mysqldump --max-allowed-packet=512M -u root -p database_name table_name > backup.sql
常见错误写法：
-
mysqldump -u root -p database_name --max-allowed-packet=512M（参数位置靠后，无效） -
mysqldump --max-allowed-packet=64 database_name ...（没写单位，实际是 64 字节） -
mysqldump --max-allowed-packet=512m（小写m，部分旧版本不识别）
为什么有时调大了还是失败？检查这三处
即使参数写对，也可能因其他环节卡住：
- MySQL 服务端的
max_allowed_packet实际生效值，要用SELECT @@max_allowed_packet;查，不是看配置文件——动态修改后没重启或没执行SET GLOBAL就不会变 - 如果通过跳板机或代理连接（比如 SSH 隧道、云数据库代理），中间链路可能有额外包大小限制，比如某些云厂商 Proxy 默认限 64M，再大也白搭
-
mysqldump导出视图或触发器时，内部拼 SQL 可能比原始数据还膨胀，建议加--skip-triggers --skip-routines --skip-events先排除干扰
替代方案：用 mysqlpump 或分块导出
mysqlpump 是 MySQL 5.7+ 提供的替代工具，原生支持大字段流式处理，默认行为更稳健，且 --default-character-set=utf8mb4 和大包兼容性更好。
若仍不行，可退到手动分块：
- 对大字段表，用
SELECT ... INTO OUTFILE按主键范围导出文本（需有FILE权限） - 用
mysqldump --where="id BETWEEN 1 AND 10000"分批次，避开单次超限 - 避免用
--tab直接导出，它依赖服务端文件系统权限，且不保证字段完整转义
真正麻烦的不是调参本身，而是得同时盯住客户端命令、服务端变量、中间链路三层的包大小策略——少一环，备份就静默截断。
