Navicat备份卡在“正在写入数据”是因单线程逐行导出引发I/O瓶颈，应禁用压缩、调大批量参数，或改用mysqldump（加--single-transaction等）或mydumper，并将备份路径设为本地SSD。
Navicat 备份卡在“正在写入数据”怎么办
这不是网络或密码问题，而是 navicat 默认用单线程、逐行 select + insert 模式导出，遇到大表（比如单表超 500 万行或 >2gb）时反复触发磁盘随机读、innodb 缓冲区抖动，cpu 占用低但 i/o 持续 100%，界面看起来像卡死。
- 先关掉「导出表数据」，只导结构——如果秒完成，说明瓶颈就在数据导出环节
- 检查 MySQL 错误日志有没有
MySQL server has gone away或Got timeout reading communication packets，有就说明连接被服务端主动断开（常见于wait_timeout或内存不足） - 把「每批记录数」从默认 1000 改成 50000，能显著减少
INSERT语句数量和解析开销 - 禁用「导出为 SQL 文件」里的「压缩备份文件」——gzip -9 压缩会吃满 CPU，且对 SQL 文本压缩率提升不到 8%，耗时却可能差 5 倍
为什么该换 mysqldump 而不是调 Navicat 参数
Navicat 底层调的很可能就是 mysqldump，但它封装掉了关键参数，导致你无法控制事务行为、锁策略和传输方式。真正可控的优化必须绕过 GUI 层。
- 用
--single-transaction替代 Navicat 的「锁定表」：InnoDB 表不锁表，只建一致性快照 - 加
--skip-triggers --skip-routines --skip-events：这些对象导出极慢且常因权限或定义冲突失败 - 指定
--max-allowed-packet=512M：防止长文本字段或大 BLOB 截断 - 导出目标路径必须是本地 SSD（如
/tmp/db.sql），别直连远程库再存到机械硬盘——I/O 路径越长越容易卡
超过 50GB 的库，Navicat 已经不适合全库导出
Navicat 对大于 2GB 的 SQL 文件支持差，导入时报 Packet for query is too large；导出过程无法暂停续传；不支持并行导出任何一张表。这不是配置问题，是架构限制。
- 改用
mydumper：C++ 写的，支持多线程、按表分文件、自带压缩，50GB 库通常能在 15 分钟内完成 - 执行前先跑这条 SQL 找出最大几张表：
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; - 对 Top 3 大表单独处理：用
SELECT ... INTO OUTFILE直接落盘，或用mysqldump --where="id BETWEEN x AND y"分片导出 - 定时任务里别选「备份数据库」，改选「运行外部程序」，路径填真实
mysqldump或mydumper可执行文件，并在命令末尾加> /path/to/backup.sql 2>&1，否则 Navicat 会一直等 stdout 输出
加密 + 压缩 + 远程写入三者叠加最容易假死
Navicat 加密备份默认走「AES-256 + 全量内存缓存」，大表会先把整个结果集加载进内存再加密写入，内存吃满就触发 swap；同时写入 NAS 或远程共享盘时，SMB/CIFS 缓存策略又和 Navicat 的小块 flush 冲突；再加上 gzip -9 压缩，CPU、内存、I/O 全线告急。
- 加密时务必调低「内存使用限制」至 128MB（默认常是 1024MB）
- 勾选「启用流式备份」（v16+ 才有），避免全量缓存；若灰显，检查是否用了 ODBC 或旧版 libpq 驱动
- 备份目标路径避开
~/Documents或桌面，换成独立挂载的 NVMe SSD（如/Volumes/BackupSSD） - 想保留加密又提速？用
mysqldump导出后，再用openssl aes-256-cbc -salt -in db.sql -out db.sql.enc流式加密，更稳也更可控
innodb_buffer_pool_size、max_allowed_packet），否则换什么工具都只是把压力换个地方堆砌。
