Navicat 还原大备份卡在 99% 或断连，主因是 max_allowed_packet 过小或 wait_timeout 触发空闲断连；需修改 my.ini/my.cnf 中 [mysqld] 下 max_allowed_packet=256M 和 wait_timeout=86400、interactive_timeout=86400，并完整重启 MySQL；避免 SQL 格式导入 BLOB，改用 XML 导出（启用 CDATA 与压缩）；超 2GB 文件应弃用 Navicat，改用 mydumper 或 mysqldump+binlog 恢复。
max_allowed_packet 不够大会静默断连
navicat 还原大备份时卡在 99% 或报 lost connection to server，大概率不是网络问题，而是 mysql 服务端因单条 sql 超过 max_allowed_packet 主动关闭连接——不报错、不提示，只让客户端干等。
- 先查当前值：
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';，若显示4194304（4MB）或16777216（16MB），基本就是瓶颈 -
SET GLOBAL max_allowed_packet = 268435456;是临时生效，Navicat 新建连接不会继承，无效 - 必须改配置文件：
my.ini（Windows）或/etc/my.cnf（Linux/macOS），在[mysqld]下加一行：max_allowed_packet = 256M - 改完必须完整重启 MySQL 服务（不是重载），否则不加载；重启前建议执行
FLUSH TABLES;
wait_timeout 触发空闲断连
即使 max_allowed_packet 调大，还原仍可能中断——因为 Navicat 批量写入间隙超过服务端默认的 wait_timeout（通常 28800 秒），MySQL 就会 KILL 连接。
-
SET GLOBAL wait_timeout = 86400;只对当前会话有效，Navicat 导入用新连接，不生效 - 同样要改配置文件，在
[mysqld]下追加：wait_timeout = 86400和interactive_timeout = 86400 - Navicat 连接属性 →「高级」页签 → 勾选
Keep connection alive（部分版本支持），或手动在连接字符串末尾加参数：?connect_timeout=60&read_timeout=3600
SQL 格式导入对 Blob 是自毁式操作
Navicat 默认导出/导入用 SQL 格式，对 BLOB、MEDIUMTEXT 等字段极其危险：二进制内容被转成十六进制字符串（如 0x89504E47），体积翻倍，同时撞上 net_buffer_length 和 max_allowed_packet 双重限制。
- 放弃 SQL 格式：右键表 →「导出向导」→ 格式选
XML→ 勾选「使用 CDATA 包裹二进制数据」和「压缩导出文件」 - XML 模式把 Blob 当独立节点处理，绕过 SQL 解析器，不受
net_buffer_length影响 - 导出路径不能含中文、空格或特殊符号，否则 Navicat 可能读取失败
- 导出后用文本编辑器打开 XML 文件，确认 Blob 内容在
里，而不是十六进制字符串
超 2GB 的 SQL 文件别硬扛
Navicat 对大于 2GB 的 SQL 文件支持差，导入时容易报 Packet for query is too large，且不支持暂停续传、无法并行、无进度反馈。
- 50GB 以上库直接放弃 Navicat 全库导入，改用
mydumper（C++ 实现，支持多线程、按表分文件、自带压缩） - 导出前先定位大表：
SELECT table_name, round(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES WHERE table_schema = 'your_db' ORDER BY size_mb DESC LIMIT 5; - 若只是恢复某时间点，优先用
mysqldump --master-data=2+mysqlbinlog组合，比全量 SQL 更可靠
SHOW GLOBAL VARIABLES 输出是否已更新。
