Navicat 15 同步数据时内存占用高，因其不支持流式查询，所有操作均采用全量加载+内存缓存；有效降压方式包括：设每批记录数为5000～10000、关闭非必要比对选项、先导出SQL再用命令行导入。
navicat 15 同步数据时内存占用高，不是因为没开“流式查询”——它压根不支持这个功能。 所有“开启流式查询”的说法都是误传。navicat 15 的数据同步（data transfer）和数据同步（data synchronization）两个模块，底层都采用全量加载 + 内存缓存方式处理记录，无法像 jdbc 的 setfetchsize(integer.min_value) 那样启用真正的流式拉取。
为什么 Navicat 15 没有流式查询选项
Navicat 是封闭客户端，其数据传输逻辑由 PremiumSoft 自行封装，未暴露底层 fetch size、streaming result set 等 JDBC/ODBC 参数控制入口。你能在设置里看到的“批量大小”“每批记录数”，只是控制分段提交的粒度，不是流式：每一批仍需完整加载到本地内存再发往目标库，中间无释放机制。
- 即使勾选了“直接表/视图复制”，Navicat 仍会先读取源表元信息、构建临时映射结构、校验字段兼容性——这些都在内存中完成
- “数据同步”（对比并更新差异行）更重：它必须把源表和目标表的主键+比对字段全部载入内存做哈希匹配
- 所有日志、进度条、中断恢复状态也都依赖内存缓存，无法绕过
真正有效的内存降压手段（实操级）
放弃“流式幻想”，转而用可落地的配置与流程控制内存峰值：
- 在“数据传输”向导中，手动设死“每批记录数”为 5000～10000（别信默认值）。大于 2 万极易触发本地 OOM；小于 1000 则网络往返开销陡增
- 关闭“比较数据”和“同步时间戳”等非必要选项——它们会额外加载字段进内存做逐行比对
- 先导出为 SQL 文件（勾选“仅 INSERT”“禁用外键检查”），再用
mysql命令行导入：mysql -u root -p database_name 。命令行不走 GUI 内存池，实际内存占用下降 60%+ - 若同步涉及大文本/二进制字段（
TEXT、BLOB），务必在 SQL 语句中显式排除：SELECT id, name, created_at FROM t_user—— 绝不用SELECT *
容易被忽略的隐性内存炸弹
你以为只在点“开始同步”时才吃内存？错。以下操作早已悄悄占满内存：
- 连接后双击打开一张千万级表——Navicat 默认加载前 1000 行，但后台已预读索引统计、字段类型推断、甚至自动采样分析，
SHOW TABLE STATUS和EXPLAIN结果全驻留内存 - 使用“查询构建器”拖拽生成 SQL 时，每次修改条件都会缓存历史执行计划，累积不释放
- “自动保存查询”和“最近打开对象”列表过长（尤其含大结果集标签页），会持续持有内存引用，关 tab 也不清
- Windows 下若 Navicat 安装在 C 盘，且启用了“自动备份”，
%AppData%\Roaming\PremiumSoft\Navicat\Backup目录可能堆积数 GB 临时快照文件，间接加剧内存压力
最麻烦的点在于：Navicat 不提供实时内存监控面板，你无法知道哪一步卡在了内存分配上。真要压测，得配合 Windows 任务管理器看 navicat.exe 的“专用工作集”曲线，再对应操作节点——否则所有“调大 JVM 内存”的猜测都是空谈。
