根本原因是误选“仅结构”导出模式，导致.psc文件仅有CREATE TABLE语句而无INSERT；此外max_allowed_packet过小、权限不足、事务回滚或自动备份环境变量失效也会造成文件为空或缺失数据。
备份任务显示成功但 .psc 文件为空或只有表结构
根本原因不是 navicat“没干活”，而是它按你选的模式执行了——最常见的是误选了「仅结构」，导致生成的 .psc 文件里只有 create table 语句，没有 insert。这类文件用 navicat 打开时看起来“对象齐全”，但双击任意表却查不到一行数据。
检查方法很简单：右键该 .psc 文件 →「打开方式」→ 用记事本或 VS Code 打开，搜索 INSERT INTO。如果完全搜不到，基本就是导出模式错了。
- 导出向导中务必确认勾选的是「数据和结构」，不是「仅结构」或「仅数据」
- 若目标库含大量大文本字段（如
TEXT、JSON），即使选了「数据和结构」，也可能因max_allowed_packet过小被截断——此时文件有部分INSERT，但大表缺失 - 「高级」选项里若勾选了「使用事务」，而某张表在导出中途触发锁等待超时，整个事务回滚，结果就是文件生成了但内容为空
Navicat 17 的 .psc 文件实际是压缩包，可手动解压验证
.psc 不是纯文本 SQL，而是 Navicat 自定义的 ZIP 压缩格式。直接双击打开只能看到逻辑视图，无法判断底层是否真有数据。真正可靠的验证方式是解压看内容：
- 把
.psc后缀改成.zip，用解压工具打开 - 进入
data/目录，找对应表名的.sql文件（如users.sql） - 打开该文件，确认是否包含
INSERT INTO `users` VALUES ...语句
如果 data/ 目录下只有空文件夹，或所有 .sql 文件都只含 CREATE，说明备份过程确实没写入数据——问题出在导出配置或权限，而非文件损坏。
导出时用户权限不足也会导致“静默丢数据”
Navicat 导出依赖当前连接账号的 SELECT 权限。但很多人忽略一点：如果账号只被授予了部分列的查询权（比如 GRANT SELECT(id,name) ON db.tbl TO 'u'@'%'），而 Navicat 默认尝试 SELECT *，那么整行数据会被跳过，最终导出为空。
这种情况下任务仍显示“成功”，因为 Navicat 没报错，只是没拿到任何有效行。
- 用该账号登录 MySQL 命令行，执行
SHOW GRANTS;，确认是否有完整表级SELECT - 临时换用
root或高权限账号重试导出，快速定位是否权限问题 - 若必须用受限账号，导出前在「高级」→「字段」里手动勾选明确有权限的列，避开无权字段
备份任务调度执行时环境变量失效
如果你是通过 Navicat 的「自动备份任务」定时执行（而非手动点击），要注意：后台服务运行时可能不继承桌面用户的环境变量，特别是 MySQL 客户端路径、字符集、SSL 配置等。这会导致 Navicat 底层调用 mysqldump 失败，但界面仍显示“完成”。
典型表现是：手动导出正常，定时任务导出的 .psc 文件体积极小（如几 KB），且解压后 data/ 目录为空。
- 打开 Navicat「工具」→「选项」→「备份」，确认「MySQL 路径」指向正确的
mysqldump.exe（如C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqldump.exe） - 检查「高级」→「字符集」是否与源库一致，避免因编码不匹配导致 dump 进程提前退出
- 任务日志默认不记录详细错误，需在「计划任务」设置里勾选「记录详细日志」，然后去
%AppData%\PremierSoft\Navicat\Logs\查看真实报错
真正容易被忽略的是：Navicat 17 的自动备份任务在 Windows 服务模式下运行时，若数据库启用了 SSL 连接，而服务账户没有读取证书文件的权限，mysqldump 会静默失败——界面不提示，日志也不报 SSL 错误，只留下一个空壳 .psc 文件。
