Navicat 17 GUI备份大表易卡死或超时，因其不支持流式分块导出；应改用「转储 SQL 文件」并手动添加WHERE条件分片，如WHERE id BETWEEN 1 AND 100000，按主键范围分批导出。
直接备份千万级大表会卡死或超时
Navicat 17 的 GUI 备份（Backup）默认走的是客户端拉取数据流 + 本地序列化为 .psc 或 .nb3 包的路径，对单表超 500 万行、带自增主键的表极易触发内存溢出、连接超时（MySQL server has gone away）、或 Navicat 自身无响应。这不是配置问题，是架构限制：它不支持流式分块导出，也不控制 SELECT 的 LIMIT/OFFSET 或游标分页。
必须改用「转储 SQL 文件」并手动加 LIMIT 分片
对带自增主键的大表，唯一可控的方式是右键表 → 「转储 SQL 文件」→ 选「结构和数据」→ 在「高级」选项里勾选「使用 INSERT DELAYED」（MySQL）或「使用 COPY 命令」（PostgreSQL），但关键一步是：**手动在导出前加 WHERE 条件分片**。Navicat 不提供图形化分片界面，你得自己估算主键范围：
- 先查最大 ID：
SELECT MAX(id) FROM huge_table; - 按每 10 万行切一片，比如
WHERE id BETWEEN 1 AND 100000，导出为huge_table_001.sql - 重复执行，每次更新
BETWEEN范围，直到覆盖全部 ID - 注意：自增主键可能有空洞，用
id >= ? AND id 比 <code>BETWEEN更安全，避免漏行
备份文件里自增主键值会被保留，还原时需重置
用「转储 SQL 文件」导出的 INSERT 语句含显式主键值（如 INSERT INTO t (id, name) VALUES (123456789, 'xxx');），还原时会直接写入该值，不触发自增逻辑。这会导致后续插入冲突。还原后必须手动重置自增起点：
- MySQL：
ALTER TABLE huge_table AUTO_INCREMENT = ?;（? 设为导出数据中最大id+ 1） - PostgreSQL：
SELECT setval('huge_table_id_seq', (SELECT MAX(id) FROM huge_table)); - 别跳过这步——否则第一次新插入就报
Duplicate entry
别碰「备份」按钮，也别信「逻辑连接聚合」能加速
有人试过把大表所在库拖进“逻辑连接”分组再右键，以为能触发优化；实际没用。Backup 功能完全无视逻辑分组，仍按单库单连接硬执行全量 SELECT。更危险的是：它默认不加 SQL_NO_CACHE，可能把 MySQL 查询缓存打爆，拖慢线上业务。真正要保稳定，就老实用「转储 SQL 文件」+ 分片 + 手动重置自增。复杂点在于分片脚本得自己写，但这是目前唯一不依赖第三方工具、不改应用代码、且 Navicat 17 原生支持的路径。
