错误Error 2020源于MySQL服务端max_allowed_packet限制导致数据包超限，需永久修改mysqld配置中max_allowed_packet值（如256M），并重启服务，同时mysqldump命令需显式指定--max-allowed-packet参数，必要时配合--skip-extended-insert或单独导出大字段表。
导出报错 Error 2020: Got packet bigger than 'max_allowed_packet' bytes，说明 mysqldump 在读取某张表（比如含大 BLOB 或长文本）时，服务端返回的单个数据包超限——不是文件大小问题，是 MySQL 服务端拒绝把整行/整块数据打包发给客户端。
查当前限制和实际包大小
先确认是不是真卡在这儿：连上 MySQL，执行
SHOW VARIABLES LIKE 'max_allowed_packet';
返回值单位是字节（比如 4194304 = 4MB）。再看报错信息里的数字，例如 Got packet bigger than 'max_allowed_packet' bytes (8808741 > 4194304)，左边是实际要发的包大小（8.4MB），右边是当前上限（4MB）——差得明显，就得调。
永久修改 mysqld 的 max_allowed_packet
只改客户端或临时 SET 没用，mysqldump 是客户端，但它依赖服务端能否把大数据“吐出来”。必须改服务端配置：
- 找到真实生效的配置文件：
SHOW VARIABLES LIKE 'config_file';（常见路径：/etc/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf、宝塔是/www/server/mysql/my.cnf） - 在
[mysqld]段下加一行：max_allowed_packet = 256M（注意大写M，别写256MB或256m） - 重启服务：
sudo systemctl restart mysql（Debian/Ubuntu）或sudo systemctl restart mysqld（RHEL/CentOS）
导出时显式指定客户端参数
即使服务端调大了，mysqldump 默认仍按旧连接参数工作。安全做法是导出命令里直接带参：
mysqldump --max-allowed-packet=256M -u root -p database_name > dump.sql
如果还含四字节字符（emoji、生僻汉字），加 --default-character-set=utf8mb4 防解析中断；若表里有 BLOB 字段，可加 --hex-blob 避免二进制内容干扰协议解析。
避免导出结构本身触发超限
有些表字段本身不大，但 mysqldump 默认把几千行合并成一条 INSERT INTO ... VALUES (),(),()...，导致单语句体积爆炸。这时光调包大小治标不治本：
- 加
--skip-extended-insert：每行生成独立INSERT，包体积可控，但导入会慢些 - 加
--single-transaction（InnoDB 表）：减少锁表时间，也间接降低长事务对包缓冲的压力 - 对已知含大字段的表单独导出：
mysqldump --max-allowed-packet=512M -u root -p db table_with_blob > blob_table.sql
真正容易被忽略的是：设成 1G 后还报错，往往不是参数不够，而是某条记录的 BLOB 字段本身就接近 1G ——MySQL 协议封装开销会让实际包更大，且部分版本对单行长度有隐式硬限制。这种场景该考虑业务层拆分存储，而不是继续堆高 max_allowed_packet。
