Navicat 默认全量加载 BLOB 字段导致内存溢出和传输卡死，根本原因是客户端将整行 BLOB 数据读入内存再渲染预览；BLOB 长度限制仅控制显示字节数，不影响实际传输；应通过 SQL 规避、服务端配置、禁用 Client export 模式及使用 Server export 等方式解决。
Navicat 默认全量加载 BLOB 字段，不是“显示慢”，是“传输+内存爆了”
根本原因不是网络或磁盘，而是 navicat 在执行 select * 或未加限制的查询时，会把整行 blob 数据（哪怕单个字段 50mb）从数据库完整读入本地内存，再尝试渲染预览——这一步就卡死或触发 oom。你看到的“同步缓慢”，其实是客户端在等一个永远收不完的数据包。
常见错误现象包括：
- 同步任务卡在 “Fetching rows…” 超过 1 分钟，Navicat 进程 CPU 占用飙升、内存持续上涨
- 导出 SQL 文件时生成超大体积（比如 2GB 的 .sql），远超实际文本内容大小
- 报错
MySQL server has gone away或Out of memory，但数据库本身负载正常
别信“BLOB 长度限制”设置，它只管显示，不管传输
工具 → 选项 → 数据 → BLOB 长度限制 这个值（默认可能是 1048576）仅控制结果网格里显示多少字节的十六进制预览，**完全不影响 SELECT 语句实际返回的 BLOB 字节数**。哪怕你设成 1，Navicat 仍会把整个 BLOB 字段内容拉下来，只是不显示而已。
真正起作用的只有这些：
- SQL 层面主动避开全量加载：用
LENGTH(blob_col)、HEX(LEFT(blob_col, 8))替代直接查blob_col - MySQL 服务端配置
max_allowed_packet必须 ≥ 单个最大 BLOB 大小，否则连接直接中断 - Navicat 自身关闭
将结果保存在内存中（路径：工具 → 选项 → 其他 → 查询结果），改用临时文件缓存
同步含 BLOB 表的正确做法：绕开客户端中转
用 Navicat 做跨库同步时，如果源表含 BLOB，必须禁用 Client export 模式。否则数据先从源库→Navicat 内存→目标库，等于双倍搬运、双倍解压、双倍内存压力。
实操建议：
- 导出端选
Server export (SQL file)，确保源库secure_file_priv可写 - 导入端用
LOAD DATA INFILE或目标库原生导入工具（如 MySQL Shell 的util.importTable()） - 若必须用 Navicat GUI 导入 CSV/Excel，请先用
SELECT id, LENGTH(blob_col), created_at FROM t同步元数据，BLOB 字段单独用mysqldump --tab+mysqlimport处理 - 对超大 BLOB（>10MB），直接放弃 SQL 同步，改用对象存储中转（如 OSS/S3 + 预签名 URL 下载）
macOS/Linux 上 BLOB 同步更慢？Qt SQL 模块真拖后腿
Navicat 在 Windows 用 COM 组件直调 MySQL C API，而 macOS/Linux 依赖 Qt SQL 模块做中间层。这个模块对二进制字段序列化效率低，且不支持并行 chunk 读取——意味着 100 万行带 BLOB 的表，在 Mac 上可能比 Windows 慢 3–5 倍。
能做的有限但关键：
- 升级到
Navicat 16.1.7+，修复了旧版 zlib 版本不兼容导致的连接失败问题 - 同步前在连接属性 →
高级标签页勾选Use compression，压缩虽不能减小 BLOB 体积，但能压掉大量重复字段名和 JSON 结构开销 - 避免在 macOS 上用 Navicat 同步 >1GB 的 BLOB 表；优先切到 Linux 服务器跑
mysqldump+pv管道，速度更稳
