navicat默认同步千万级数据会崩，因其采用全表select+insert模式，无流式处理，导致内存溢出、超时中断；必须启用高级模式分块（如where id between）、禁用外键索引、调优数据库参数，并在500万行以上改用mysqldump或load data等原生命令。
navicat for mysql 同步千万级数据时，默认方式大概率失败或极慢——不是软件不行，而是它默认开启全表事务、单次加载、内存缓冲无分片控制，遇到 500 万以上记录就容易卡死、oom 或超时中断。
为什么 Navicat 默认同步在千万级会崩？
根本原因在于它的「数据同步」功能底层仍依赖 SELECT + INSERT 批量语句，而非原生 LOAD DATA INFILE 或流式管道：
- 全表拉取到本地内存再逐批插入，源表 1000 万行 ≈ 占用数 GB 内存（尤其含 TEXT/BLOB 字段）
- 目标库若启用了
innodb_flush_log_at_trx_commit=1和完整约束校验，每批 INSERT 都触发刷盘和索引更新 - Navicat 不自动禁用外键/唯一索引，导致每条 INSERT 都做全索引扫描比对
- 网络传输层无压缩，1000 万行 × 平均 200 字节 ≈ 200MB 原始数据往返，易受丢包或超时影响
这不是配置问题，是架构限制。强行点“开始”只会看到进度条卡在 3%、内存飙升、最后报 Connection lost 或 MySQL server has gone away。
必须开「高级模式」并手动分块传输
千万级起步，必须跳过默认流程，进「高级模式」切片执行。否则同步中途失败，重来就得从头开始。
- 在「数据同步」窗口选中表后，点击右下角
高级按钮 - 勾选
自定义记录集，不要用「全部记录」 - 用主键（最好是
id）分段，例如：WHERE id BETWEEN 1 AND 100000，每次传 10 万行 - 更稳的做法：用「记录集生成器」→ 选择按主键范围自动拆分，生成多个任务配置文件（.ncf）
- 每个分块任务单独运行；失败只影响当前块，重跑该块即可
注意：ORDER BY id 不要加——Navicat 自动加会导致全表排序，拖慢速度；只要 WHERE 条件能走索引就行。
同步前必须做的三件事
不提前处理结构和参数，分块也救不了你：
- 目标库先建好表结构，且 删掉所有外键约束和非必要索引（同步完再重建）
- 确认源库和目标库的
sql_mode一致，尤其避免STRICT_TRANS_TABLES导致空字符串/零日期被拒 - 目标库临时调大参数：
innodb_buffer_pool_size（至少 4G）、max_allowed_packet（建议 512M）、wait_timeout（设为 28800）
如果目标表已有数据，且需保留差异，请在「选项」里只勾选 插入记录 和 更新记录，**一定取消勾选 删除记录**——否则 Navicat 会先查出目标表哪些 ID 源表没有，再发 DELETE，千万级下这一步就可能耗时几十分钟甚至锁表。
真正百万级以上，别硬扛 Navicat
当单表超过 500 万，尤其是含 JSON、TEXT 或宽字段时，Navicat 的分块能力已逼近极限：它无法跳过已成功导入的 ID 范围做断点续传，也不能跳过特定错误行继续（比如某条数据编码异常），更没法绕过 secure_file_priv 限制走 LOAD DATA 加速。
这时候该换方案：用 mysqldump --where="id BETWEEN ..." 分段导出 SQL，或直接用 SELECT ... INTO OUTFILE + LOAD DATA INFILE 组合，速度能提升 5–10 倍。Navicat 只适合验证、补漏、小批量核对——把它当「操作界面」，而不是「执行引擎」。
