根本原因是误选“仅结构”导出模式，导致.psc文件仅有CREATE TABLE语句而无INSERT；此外max_allowed_packet过小、权限不足、事务回滚或自动备份环境变量失效也会造成文件为空或缺失数据。
导出模式选错：「仅结构」导致.psc里没INSERT
navicat 任务显示“成功”，但生成的 .psc 文件大小为 0 或只有几百字节，最常见原因是导出时误选了「仅结构」。这种模式只生成 create table 语句，不包含任何 insert into，所以文件极小，且用 navicat 双击打开时表看起来“存在”，但查不到数据。
验证方法：.psc 文件右键 → “打开方式” → 记事本或 VS Code，搜索 INSERT INTO。搜不到就基本坐实了。
- 导出向导中必须手动勾选「数据和结构」，别依赖默认选项
- 若目标库含大字段（如
TEXT、JSON），即使选了「数据和结构」，也可能因max_allowed_packet过小被截断——此时文件有部分INSERT，但大表内容为空 - 「高级」里勾了「使用事务」，而某张表锁等待超时，整个事务回滚，结果就是文件生成了但内容为空
权限不足：SELECT * 失败却不报错
Navicat 导出依赖连接账号的 SELECT 权限。但如果账号只被授予了部分列（比如 GRANT SELECT(id,name) ON db.tbl TO 'u'@'%'），而 Navicat 默认执行 SELECT *，就会静默跳过整行——导出文件里对应表的 .sql 是空的，任务仍显示成功。
排查步骤：
- 用该账号登录 MySQL 命令行，执行
SHOW GRANTS FOR 'u'@'%';，确认是否含完整表级SELECT - 临时换用
root或高权限账号重试导出，快速定位是否权限问题 - 必须用受限账号时，在「高级」→「字段」里只勾选你有权限的列，避开无权字段
.psc 是 ZIP 压缩包，直接双击看不出真假
.psc 不是纯文本 SQL，而是 Navicat 自定义的 ZIP 包。双击打开只能看到逻辑视图，无法判断底层有没有真实数据。真正可靠的验证方式是解压看内容：
- 把
.psc后缀改成.zip，用 7-Zip 或系统自带解压工具打开 - 进入
data/目录，找对应表名的.sql文件（如users.sql） - 打开该文件，确认是否含类似
INSERT INTO `users` VALUES (...)的语句 - 如果
data/下全是空文件夹，或所有.sql都只有CREATE TABLE，说明备份过程根本没写入数据
定时任务环境变量失效：后台跑脚本找不到 mysqldump
如果你用的是 Navicat 的「自动运行」功能（即注册 Windows 任务计划或 Linux cron），要注意：后台服务不继承桌面用户的环境变量。常见表现是脚本执行后生成空 .psc 或直接失败，但界面无提示。
关键检查点：
- Windows 任务计划中，“配置为”要选对版本（如 Navicat Premium 16+ 装在
Program Files，需勾选「最高权限运行」） - 「起始于(可选)」字段必须填脚本所在目录的绝对路径（如
C:\navicat_backups\），否则相对路径失效 - Linux/macOS 下 cron 环境变量极简，脚本开头需显式设置
PATH和LD_LIBRARY_PATH，或改用mysqldump替代 Navicat CLI
真正的空文件往往不是 Navicat 崩了，而是它老老实实按你给的权限、参数和模式执行了——只是你没意识到那些开关已经关掉了数据写入。
