根本原因是目标数据库所在文件系统已满，需登录目标环境执行df -h确认/var/lib/mysql等挂载点使用率≥95%或Avail为0，再清理binlog等日志并按部署形态扩容磁盘。
目标库磁盘空间不足导致同步中断，根本不是 navicat 的问题，而是目标数据库所在文件系统已满——哪怕你本地磁盘充足，只要 /var/lib/mysql 或 /var/lib/postgresql 挂载点的 avail 为 0，同步必然卡在写入阶段。
先确认真正满的是哪块磁盘
别只查自己电脑 C 盘。必须登录目标服务器（或容器、WSL）执行：
df -h
重点关注 Mounted on 列中数据库数据目录对应的挂载点，例如：
- MySQL 默认数据路径
/var/lib/mysql→ 通常归属/或/var分区 - PostgreSQL 常在
/var/lib/postgresql→ 同样看其挂载点 - Docker 容器内需运行
docker exec -it <container> df -h
若某分区 Use% ≥ 95% 或 Avail 显示为 0，就是根源。
清理数据库自身日志，快速释放空间
数据库运行时持续生成日志，最占空间的是 binlog、slow.log、error.log 和 audit 日志。不能直接删文件，得按服务规范操作：
- MySQL：执行
PURGE BINARY LOGS BEFORE '2026-05-15 00:00:00'（保留最近 30 天），避免误用RESET MASTER - 确认是否开启非必要日志：
SHOW VARIABLES LIKE 'log_%';，关掉log_output='TABLE'防止mysql.general_log表暴涨 - PostgreSQL：检查
log_directory和log_filename，启用log_rotation_age后再删旧日志 - Oracle：查
SELECT value FROM v$parameter WHERE name = 'audit_file_dest';，清空该路径下过期.aud文件
扩容要匹配部署形态，别硬扩根分区
扩容不是“加硬盘”就完事，不同环境策略差异很大：
- 云服务器（阿里云/ECS、腾讯云/CVM）：控制台「云盘扩容」→ 在线扩容 → 登录后执行
resize2fs /dev/vda1（ext4）或xfs_growfs /（xfs） - Docker 容器：重建容器并挂载更大容量卷，例如
-v /data/mysql:/var/lib/mysql；别试图改容器内磁盘 - 物理机/VMware：若
/var/lib/mysql单独挂载，可直接扩展对应 LVM 逻辑卷；若混在/下，扩根分区风险高，建议迁移数据目录
切忌对 / 分区盲目扩容——尤其当 /var 已满但 / 还有空间时，说明是子目录挂载点限制，不是根分区问题。
同步前务必验证可用空间与表空间状态
清理和扩容后，别直接开同步。先验证两件事：
- MySQL/PostgreSQL：再次
df -h确认目标挂载点Avail≥ 5GB（千万级表建议预留 ≥ 20GB） - Oracle：运行
SELECT tablespace_name, ROUND((bytes - NVL(free_bytes, 0)) / bytes * 100, 2) used_pct FROM ...查表空间使用率，≥ 95% 仍需扩展数据文件
很多失败发生在“以为满了已解决”，实际只是日志清了但表空间没动，或者扩容后没执行 resize2fs / xfs_growfs，系统仍看不到新空间。
