确认是否因max_allowed_packet过小导致恢复失败，需执行show variables like 'max_allowed_packet';若返回4194304或16777216且报错含“packets larger than max_allowed_packet”或“mysql server has gone away”，即为该参数所致；临时改用set global max_allowed_packet=536870912后须退出重连，永久改需在[mysqld]段添加max_allowed_packet=512m并完整重启服务，同时恢复命令须显式指定--max-allowed-packet=512m。
恢复失败大概率是服务端 max_allowed_packet 太小，不是备份文件大，而是单条语句或单个结果包超限。
怎么确认真是它在卡恢复？
连上 MySQL 后执行：SHOW VARIABLES LIKE 'max_allowed_packet';
如果返回值是 4194304（4MB）或 16777216（16MB），而你的报错里明确写着类似 Packets larger than max_allowed_packet are not allowed 或 Got packet bigger than 'max_allowed_packet' bytes (12345678 > 4194304)，就坐实了。
注意：MySQL server has gone away 这类错误也常是它伪装的——不是服务崩了，是包太大被主动断开。
临时改：适合紧急恢复且能重启客户端
执行：SET GLOBAL max_allowed_packet = 536870912;（即 512MB，单位必须是字节）
然后必须退出当前 mysql 客户端，再重新登录，否则 SHOW VARIABLES 看不到新值。
-
SET GLOBAL只影响新建立的连接，已连上的会话仍用旧值 - 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，这条路走不通 - 改完不退出重连，
source或mysql -e导入时照样报错
永久改：改配置 + 重启服务，缺一不可
找到真实生效的配置文件：SHOW VARIABLES LIKE 'config_file';
常见路径：/etc/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf、宝塔用户是 /www/server/mysql/my.cnf。
在 [mysqld] 段末尾添加：max_allowed_packet = 512M
注意：配置文件里可以写 512M，但命令行里只能写字节数；别写进 [client] 段，那对服务端无效。
- 必须完整重启服务：
sudo systemctl restart mysqld（Linux）或通过 Windows 服务管理器重启 - 仅
reload或flush不生效 - 重启后立刻执行
SHOW VARIABLES验证，避免段落写错或配置被覆盖 -
max_allowed_packet理论上限是1073741824（1GB），设更大没用
恢复命令本身也要配参数，否则白调服务端
即使服务端调到了 512MB，mysql 客户端默认仍按旧值（通常是 16MB）建连。所以恢复时得显式指定：mysql --max-allowed-packet=512M -u root -p database_name
- 用
source在交互式 mysql 里执行，得先运行：SET SESSION max_allowed_packet = 536870912;（注意是SESSION，不是GLOBAL） - 如果 dump 文件含长文本或 BLOB，加
--hex-blob防协议解析出错 - 若 dump 是用
mysqldump --extended-insert生成的，单条 INSERT 可能塞几千行，体积爆炸——此时加--skip-extended-insert更治本
真正容易被忽略的是：服务端、客户端、会话级三处 max_allowed_packet 各管一摊，只调一处等于没调；还有 wait_timeout 和 interactive_timeout 不同步调，大数据恢复到一半就断连，前面全白干。
