Navicat 备份卡顿主因是单线程全量导出引发I/O瓶颈，应改用mysqldump（加--single-transaction等参数）或mydumper，并优化磁盘、MySQL及系统配置。
Navicat 备份卡在“正在导出表结构”或“正在写入数据”怎么办
不是 navicat 本身坏了，而是它默认用单线程、全量 select + insert 模式导出，遇到大表（比如 innodb_file_per_table=on 的几十 gb 表）会反复读磁盘、锁表、触发 mysql 缓冲区抖动，cpu 占用低但 i/o 一直 100%，看起来像卡死。
- 关掉 Navicat 的「导出为 SQL 文件」选项里的「导出表数据」再试一次——如果秒完成，说明问题出在数据导出环节，不是结构
- 检查 MySQL 错误日志里有没有
Got timeout reading communication packets或MySQL server has gone away，有就说明 Navicat 连接被服务端主动断了（超时/内存不足） - 临时把 Navicat 的「导出设置 → 每批记录数」从默认 1000 改成
50000，减少 INSERT 语句数量，降低网络和解析开销
为什么不用 mysqldump 直接替代 Navicat 导出
因为 mysqldump 默认也是单线程，但可控项多得多：能跳过统计信息、禁用自动提交、指定压缩传输、甚至跳过某些表。Navicat 背后调的很可能就是它，只是封装掉了关键参数。
- 加
--single-transaction避免锁表（仅对 InnoDB 有效），比 Navicat 的「锁定表」更轻量 - 加
--skip-triggers --skip-routines --skip-events如果你只关心表结构和数据，这些对象导出极慢且常出错 - 用
--compress减少网络传输量（尤其跨服务器时），Navicat GUI 里根本没这个开关 - 导出到 SSD 本地路径（如
/tmp/db.sql），别直连远程库再存到本机机械硬盘——I/O 路径越长越容易卡
大库备份必须绕开 Navicat 的三个硬限制
Navicat 对大于 2GB 的 SQL 文件支持差，导入时容易报 Packet for query is too large；导出过程无法暂停续传；不支持并行导出任何一张表。
- 超过 50GB 的库，直接放弃 Navicat 全库导出，改用
mydumper（C++ 写的，支持多线程、按表分文件、自带压缩） - 执行前先运行
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;找出最大的几张表，单独处理 - 如果只是要恢复点（point-in-time），
mysqldump --master-data=2+mysqlbinlog组合比 Navicat 全量导出可靠得多
SSD 和文件系统层面最容易被忽略的性能开关
即使换了命令行工具，如果磁盘本身在拖后腿，一切优化都白搭。重点不是换硬盘，而是确认当前配置是否在“反向拖慢”。
- 检查挂载参数：
mount | grep "$(df . | tail -1 | awk '{print $1}')，确保没有noatime,nobarrier缺失（尤其是 XFS/ext4） - 确认 MySQL 的
innodb_flush_method是O_DIRECT（避免双重缓冲），否则mysqldump读数据时会跟 InnoDB 抢 page cache - 临时关闭 SELinux 或 AppArmor（测试用）：
setenforce 0，某些策略会拦截大量openat()系统调用，让小文件写入延迟飙升
真正卡住的时候，往往不是工具不行，而是你不知道它在等什么——磁盘队列深度、ext4 的 journal 模式、甚至 USB 接口供电不足，都可能让 Navicat 的进度条停在 97% 一动不动。
