Navicat还原大型备份文件超时如何处理

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 主动关闭连接——不报错、不提示，只让客户端干等。

1. 先查当前值：SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';，若显示 4194304（4MB）或 16777216（16MB），基本就是瓶颈
2. SET GLOBAL max_allowed_packet = 268435456; 是临时生效，Navicat 新建连接不会继承，无效
3. 必须改配置文件：my.ini（Windows）或 /etc/my.cnf（Linux/macOS），在 [mysqld] 下加一行：max_allowed_packet = 256M
4. 改完必须完整重启 MySQL 服务（不是重载），否则不加载；重启前建议执行 FLUSH TABLES;

wait_timeout 触发空闲断连

即使 max_allowed_packet 调大，还原仍可能中断——因为 Navicat 批量写入间隙超过服务端默认的 wait_timeout（通常 28800 秒），MySQL 就会 KILL 连接。

1. SET GLOBAL wait_timeout = 86400; 只对当前会话有效，Navicat 导入用新连接，不生效
2. 同样要改配置文件，在 [mysqld] 下追加：wait_timeout = 86400 和 interactive_timeout = 86400
3. Navicat 连接属性 →「高级」页签 → 勾选 Keep connection alive（部分版本支持），或手动在连接字符串末尾加参数：?connect_timeout=60&read_timeout=3600

SQL 格式导入对 Blob 是自毁式操作

Navicat 默认导出/导入用 SQL 格式，对 BLOB、MEDIUMTEXT 等字段极其危险：二进制内容被转成十六进制字符串（如 0x89504E47），体积翻倍，同时撞上 net_buffer_length 和 max_allowed_packet 双重限制。

1. 放弃 SQL 格式：右键表 →「导出向导」→ 格式选 XML → 勾选「使用 CDATA 包裹二进制数据」和「压缩导出文件」
2. XML 模式把 Blob 当独立节点处理，绕过 SQL 解析器，不受 net_buffer_length 影响
3. 导出路径不能含中文、空格或特殊符号，否则 Navicat 可能读取失败
4. 导出后用文本编辑器打开 XML 文件，确认 Blob 内容在 里，而不是十六进制字符串

超 2GB 的 SQL 文件别硬扛

Navicat 对大于 2GB 的 SQL 文件支持差，导入时容易报 Packet for query is too large，且不支持暂停续传、无法并行、无进度反馈。

1. 50GB 以上库直接放弃 Navicat 全库导入，改用 mydumper（C++ 实现，支持多线程、按表分文件、自带压缩）
2. 导出前先定位大表：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;
3. 若只是恢复某时间点，优先用 mysqldump --master-data=2 + mysqlbinlog 组合，比全量 SQL 更可靠

实际调参后仍失败，大概率是配置没生效或没重启服务——别信“改了就行”，一定要验证 SHOW GLOBAL VARIABLES 输出是否已更新。